Month: November 2013

设置变量GIT_CURL_VERBOSE可以帮助调试git出错

今天操作git的时候又出错了:

error: Failed connect to github.com:8080; No route to host while accessing https://github.com/zausiu/gryphon/info/refs
fatal: HTTP request failed

 

之前用公司的http代理上git, 

#git config -l

http.proxy=http://web-proxy.oa.com:8080

 

设置变量GIT_CURL_VERBOSE可以看到详细的出错情况：

#export GIT_CURL_VERBOSE=1

# git pull
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to proxy web-proxy.oa.com port 8080 (#0)
*   Trying 10.14.36.100…
* 0x23d67b0 is at send pipe head!
* STATE: CONNECT => WAITCONNECT handle 0x23df5f0; (connection #0) 
* No route to host
* Failed connect to github.com:8080; No route to host
* Closing connection #0
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to proxy web-proxy.oa.com port 8080 (#0)
*   Trying 10.14.36.100…
* 0x23d67b0 is at send pipe head!
* STATE: CONNECT => WAITCONNECT handle 0x23df5f0; (connection #0) 
* No route to host
* Failed connect to github.com:8080; No route to host
* Closing connection #0
error: Failed connect to github.com:8080; No route to host while accessing https://github.com/zausiu/gryphon/info/refs
fatal: HTTP request failed

copyright ykyi.net

 

 

 

packet captured和packet received by filter到底有什么区别

我用的是linux. 结论是 packet received by filter是tcpdump从内核中拿到的且匹配命令上行指定的过滤条件的包， packet captured是经由pcap_loop, 或 pcap_dispatch 或 pcap_next，把包交给回调处理过的包的数量。这两个数字的差值是tcpdump抓到的，还来不及处理的包。

下面是讨论的一些细节:

/////////////

tcpdump的最后输出. 592个包captured,  1184个包received by filter。。这个差值是不是表示有多少包tcpdump没来得及处理.

man tcpdump上写得好复杂，received by filter的数字取决于OS… 1. 包匹配不匹配命令行上指定的filter都算，如果匹配，有没有被tcpdump读出都算..   2. 只有匹配命令行上指定的filter的包才算，有没有被tcpdump读出都算.   3. 只有匹配filter才算，只有被tcpdump读出才算.

我的理解是：如果是第3种，那captured的数字和received by filter的数字就是一样的。 第2种的差值表示tcpdump来不及处理的包数量，理想状态上差值能为0.   第1种情况，基本上总是有差值。

我猜测我用的linux上应该是第2种情况. 

wangbin579() 10:18:54 
应该是匹配的才算received by filter，但奇怪的是，为啥你的系统，captured怎么少？
wangbin579() 10:19:30 
[root@hz0-12-157 ~]# tcpdump -i any tcp and port 36524 or 3306 -w all.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
10757 packets captured
11171 packets received by filter
334 packets dropped by kernel
wangbin579() 10:20:07 
我们这边系统，基本可以认为packets received by filter=packets captured + packets dropped by kernel

siu¹ººººººº() 10:23:38 
/homemus/tmp # time time tcpdump -i tunl0:1  -w tmp
tcpdump: listening on tunl0:1, link-type RAW (Raw IP), capture size 96 bytes
19508 packets captured
39021 packets received by filter
0 packets dropped by kernel
0.01user 0.02system 0:17.04elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+506minor)pagefaults 0swaps

real    0m17.139s
user    0m0.012s
sys     0m0.028s
wangbin579() 10:26:03 
如果是差是丢包，那么通过查看抓包文件，应该能看出很多不完整的session
siu¹ººººººº() 10:28:46 
我觉得差值是来不及写入磁盘的包.
siu¹ººººººº() 10:29:04 
再研究看看了。。谢谢啦/..
wangbin579() 10:30:03 
packets captured是pcap_loop所设置的回调函数所调用的，一旦调用回调函数，就用统计
wangbin579() 10:30:37 
有可能内核态部分和用户态部分，速度上不匹配，有延迟导致的？
siu¹ººººººº() 10:32:33 
我现在理解, received by filter是pcap库从内核中拿到的又匹配命令行上filter的包的数量， packets captured是经由pcap_loop, pcap_dispatch之类通过callback交付出去的包数量. 差值就是还没来得及处理的.
wangbin579() 10:32:48 
17s，每秒也就2000多个，不算多，用户态程序应该来得及处理

wangbin579() 10:33:58 
我这边系统很破，处理速度也比这个快，也没有来不及处理
wangbin579() 10:34:45 
看看我的：
wangbin579() 10:34:47 
[root@hz0-12-157 ~]# time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap         
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
294663 packets captured
295432 packets received by filter
693 packets dropped by kernel

real    0m17.676s
user    0m0.897s
sys     0m3.502s
wangbin579() 10:35:52 
量比你大7倍多，也没有出现来不及处理啊，当然我的是物理机，3G内存，
siu¹ººººººº() 10:36:59 
呃 那你觉得这个差值不是来不及处理的包么？。我觉得应该还是来不及处理的。我在想，可能是写到的磁盘文件系统是NFS之类的 ….我继续排查一下。
wangbin579() 10:37:43 
有可能，我的是写入本地磁盘。
wangbin579() 10:37:58 
你这种情况，我还是第一次碰到
siu¹ººººººº() 10:39:05 
我先去运维那边了解下情况…多谢啦 
wangbin579() 10:39:18 
算涨见识了，还以为一般dropped by kernel为0就代表不丢包呢，居然还有你这种情况。
你可以看看抓包文件，session是不是很多不完整，如果不完整，你的推测是对的
siu¹ººººººº() 10:39:58 
嗯。呵呵~~ 做IT，每天都会碰到挑战宇宙规律的现象。
siu¹ººººººº() 10:40:07 

мe(～ o мe(632813052) 10:41:09 
呵呵
wangbin579() 10:41:24 
其实，网络方面的问题，最复杂了。
我现在已经陷入到网络的汪洋大海之中了，各种各样的问题都会有，而且没有尽头。
早知道如此，3年前我就不搞这一块了
siu¹ººººººº() 10:42:30 
同感。写一点点代码，都非常难以调试。各种认为理所当然的假设，通通是bug的温床

@wangbin579  麻烦你在tcpdump前加个time，。。把输出贴出来。我好像看出问题来了。

[root@hz0-12-157 ~]# time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap         
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
294663 packets captured
295432 packets received by filter
693 packets dropped by kernel

real    0m17.676s
user    0m0.897s
sys     0m3.502s
wangbin579() 10:56:03 
不是加了time了吗？
wangbin579() 10:57:15 
[root@hz0-12-157 ~]# time time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
^C202061 packets captured
202523 packets received by filter
369 packets dropped by kernel
0.66user 2.50system 0:11.99elapsed 26%CPU (0avgtext+0avgdata 24208maxresident)k
0inputs+105656outputs (0major+660minor)pagefaults 0swaps

real    0m11.999s
user    0m0.661s
sys     0m2.506s
wangbin579() 10:57:26 
加两个，结果如上
siu¹ººººººº() 10:59:29 
问题找到的。我这边运行的tcpdump，根本就没有抢到cpu时间来处理.
wangbin579() 11:00:05 

siu¹ººººººº() 11:00:06 

Real  0m3.914s

User  0m0.008s

Sys   0m0.000s

跑了4秒钟，用户空间才抢到0.008秒，内核态几乎是0 ….
siu¹ººººººº() 11:00:25 
那个差值确实是没有来得及处理的包的数量。
wangbin579() 11:00:41 
奥，那你系统这么繁忙啊

siu¹ººººººº() 11:02:22 
所以，解决了一个问题又会有新的颠覆宇宙规律的问题…系统负载很高，但cpu使用率很低。。

copyright ykyi.net

 

昨天解决了tcpcopy的一个小却很重要的bug.

tcpcopy的基础函数有个bug，流量比较大的时候，内核buffer满了。send系统调用发不完用户缓冲中的数据才会出现。然后加入了tcpcopy的QQ群，和作者稍稍讨论了一点时间。问了关于写论文和tc_session.c过于复杂的问题。

(wangb) 10:00:55 
https://github.com//tcpcopy/pull/162
(wangb) 10:01:04 
The bug arises when send system call returns with part of data transfered
and part of data still need to be sent again.
(wangb) 10:01:13 
常见于压力比较大的场合
(wangb) 10:02:14 
当然如果系统参数设置好的话，这样的情况不常见。这也是为啥我这边无法重现的原因所在
(wangb) 10:02:46 
当然昨天在开发gryphon，貌似遇到过一次
(wangb) 10:03:06 
gryphon给的压力，有时候真不是一般快和大
siu1ooooooo(16236914) 10:03:14 
我在tcpcopy上作二次开发。碰到了个bug，最后追踪到了 tc_socket_send函数。
siu1ooooooo(16236914) 10:03:52 
流量比较大的时候，内核buffer满了。send系统调用发不完用户缓冲中的数据才会出现。
siu1ooooooo(16236914) 10:05:21 
希望能贡献更多代码的。。但是tc_session.c这个模拟tcp状态机的代码太难看懂了。
(wangb) 10:05:49 
有些bug，程序员自身很难发现，往往需要依赖于用户的反馈，当然有上面的bug提出，就更好了
tc_session.c这个模拟tcp状态机，其实不仅模拟tcp状态机，而为复杂的是模拟上层应用交互
光模拟tcp状态机，是远远不够的
siu1ooooooo(16236914) 10:07:27 
有个想法， 把TCP的11个标准状态加入到tc_session中。可不可以做的。.
(wangb) 10:09:13 
数据是死的，但测试服务器是活的。应该可以吧，但加入可能会更复杂。tc_session.c这个会进一步改进的，代码需简化和功能需独立，使其易懂
siu1ooooooo(16236914) 10:09:31 
🙂
(wangb) 10:10:33 
2010～2012.5月，初步探索阶段；2012.5～2014.5，为进一步探索阶段 2014.5～以后，进一步优化
因为tcpcopy刚开始，开发人员是无法知道复杂的互联网的各种应用的特性的，只有积累到一定程度，才能进一步优化。与其说是开发，不如说是探索
siu1ooooooo(16236914) 10:12:10 
期待工程paper  
siu1ooooooo(16236914) 10:12:43 
tcpcopy稳定到了一个版本。先别加功能了。写paper吧  
siu1ooooooo(16236914) 10:13:01 
投中EI应该问题不大。
siu1ooooooo(16236914) 10:13:55 
中了paper，贡献者会迅速增多。
wangb() 10:15:43 
其实写过sigcomm论文，但被拒，说应该投USENIX ATC
wangb() 10:16:18 
I don't think that the research contribution of the paper is a good match for Sigcomm. Perhaps it would be a better match for 
a more practice-oriented conference like USENIX ATC. 
siu1ooooooo(16236914) 10:16:50 
后来呢
wangb() 10:17:05 
确实，tcpcopy是基于实践的，从实践中摸索爬行的。后来我就先不写论文了
siu1ooooooo(16236914) 10:17:22 
嗯。这是个工程实践性很强的探索啊
wangb() 10:17:27 
要写论文，必须要有条件
siu1ooooooo(16236914) 10:17:45 
喔。
wangb() 10:18:06 
从交换机或者其它设备。镜像过来，这样测试系统和在线系统就没有关联，这样的论文是能够中USENIX ATC
的
wangb() 10:19:13 
tcpcopy最高端的应用，就是在交换机，利用分光镜或者其它镜像设备，利用高性能硬件，把用户的请求数据包复制给测试系统，可惜我没有这样的条件
wangb() 10:19:38 
要是有这样的条件，我肯定要写论文了
siu1ooooooo(16236914) 10:19:55 
呃。。没怎么看懂  
siu1ooooooo(16236914) 10:21:49 
是说复制的流量要非常非常大才能中论文么
siu1ooooooo(16236914) 10:21:59 
而非常大的流量需求硬件支持
wangb() 10:22:02 
twitter梦想的测试环境，其实完全可以用我们的tcpcopy来实现。交换机上面不是有来来往往的数据包吗？在那上面把请求数据包镜像到测试系统，测试系统搭一个跟在线类似的完整系统，这样测试系统跟在线系统承受类似的压力
wangb() 10:22:17 
高端大气，才能中论文
wangb() 10:22:48 
屌丝环境，写论文，还不被批啊
siu1ooooooo(16236914) 10:23:14 
呃。是 。。。明白了。。想起以前学校的事情，懂了。
wangb() 10:24:38 
总之，tcpcopy值得你去研究，期望有更多接班人把思想传承下去，代码可以推掉重来
wangb() 10:25:10 
只要tcp协议还存在，这个思想，应该是最先进的，无法再先进了
siu1ooooooo(16236914) 10:26:11 
需要好多的开发时间啊。..嗯。先上班了啊。多谢wangbin….
wangb() 10:27:16 
慢慢来，这方面反正国外没有人做

copyright ykyi.net

为什么我的名字没有出现在github的contributor列表中.

为什么我没有出现在github.com的contributor列表中.

我提交了commit，但为什么我没有出现在贡献者列表中呢。有三个原因：

1. 检查你的commit中的邮箱信息，这个邮箱必须和你的github.com账号关联。怎么关联邮箱账号呢。先选择Account Setting, 在左边先Emails，于是就看到可以verify邮箱地址的页面了。关联邮箱地址后还有过一段时间，贡献者列表才会更新。

2. 如果工程的贡献者名单列表超过了100个。就不会显示100个以后的贡献者了。官方HELP中说这是为了性能的考量。我觉得是码农偷懒，必竟这个需求太小了。绝大多数工程不会超过100个贡献者，于是码农不想解决这个小问题。

3. 你的commit必须被提交到工程的默认分支上。如果提交到其它的分支上，你的名字就不会被显示。

 

为什么我没有出现在github.com的contributor列表中.

我提交了commit，但为什么我没有出现在贡献者列表中呢。有三个原因：

1. 检查你的commit中的邮箱信息，这个邮箱必须和你的github.com账号关联。怎么关联邮箱账号呢。先选择Account Setting, 在左边先Emails，于是就看到可以verify邮箱地址的页面了。关联邮箱地址后还有过一段时间，贡献者列表才会更新。

2. 如果工程的贡献者名单列表超过了100个。就不会显示100个以后的贡献者了。官方HELP中说这是为了性能的考量。我觉得是码农偷懒，必竟这个需求太小了。绝大多数工程不会超过100个贡献者，于是码农不想解决这个小问题。

3. 你的commit必须被提交到工程的默认分支上。如果提交到其它的分支上，你的名字就不会被显示。

 

copyright ykyi.net

 

 

 

如何删掉github上的master分枝.

假设，代码已经被clone到了本地。第一步要做的就是创建一个新的分支，比如placeholder，然后用-D从本地删除master分支。

git branch placeholder
git checkout placeholder
git branch -D master

如果现在删除github上的master，会报错：

git push origin :master

报错结果大概是这样：

remote: error: refusing to delete the current branch: refs/heads/master
To git@github.com:matthew-brett/datarray.git
! [remote rejected] master (deletion of the current branch prohibited)
error: failed to push some refs to 'git@github.com:matthew-brett/datarray.git'

正确地做法是先checkout到新建的placeholder分支。然后把placeholder推送到github上。

git checkout placeholder # if not on placeholder already
git push origin placeholder

从github的web端入到工程的setting界面，有个地方可以更改默认的分支，用另一个分支做默认分支，而不是master。现在就可以从删掉master了

git push origin :master

另，怎么给github上一个tag更名等:

1) 删除本地的一个tag: git tag -d v0.4
2) 删除GitHub上一个tag (这会删除掉下载链接): git push origin :v0.4
3) 给当前branch打标签: git tag -a v0.5 -m "Version 0.5 Stable"
4) 把所有tag推上github(two dashes): git push --tags

copyright ykyi.net