（後日、libedit.2.dylib 入れ直した で解消した。）
おもむろに python と叩いてみたら、
Apple製のは Bus error おこしてくれて対話型のがつかえないことに気づいた
(書いたスクリプトの実行は可)
% /usr/bin/python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
zsh: bus error /usr/bin/python
ためしに MacPorts でいれてみたブツは生きてる
% /opt/local/bin/python2.6
Python 2.6 (r26:66714, Oct 27 2008, 01:12:42)
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
% /opt/local/bin/python3.0
Python 3.0rc1 (r30rc1:66499, Oct 27 2008, 01:06:24)
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
なんだろなー。。
2.5系も MacPorts のいれればいい・・・のか？
2008年10月27日月曜日
2008年10月4日土曜日
26秒の怪
症状:
cvs がもっさりしている(update やら checkout が始まるのに時間がかかる)
2ヶ月まえくらいから発生していた(らしい)
制限事項:
cvs のサーバには ssh ログインすることはできない
緊急ではなかったけど、放置しておくのもなんだかな、、と思ったので調べた。上記制限事項により、クライアント側からのみ、の調査に留まる。
方法:
tcpdump
wireshark
メモしてなかったけど、Mac OS X のターミナルでだいたい以下のように実行、、
$ sudo tcpdump -n -x -l -v -w ~/Desktop/cvs.tcpdump port 2401
しつつ、cvs checkoutやらupdate を実行して採取した。
ふむ、、、おそい。たしかにおそい。ためしに3回採取し、wireshark で解析。
するとすぐ目についたのが、
「26秒の待ち」。3回とも一様に待ちが発生している。
サーバには入れないので、これを手がかりに調査 & 社内のネットワークのプロに聞く。
すると、、某アプライアンス機器が弾いているという。
しかし26秒てなんだ、、と思って調べていると、 どうも ucspi-tcp パッケージ の tcpserver プログラム が怪しいことに気づく。
http://cr.yp.to/ucspi-tcp/tcpserver.html より
「タイムアウト」の時間が 26秒なので、タイムアウトする以前に、機能自体を無効にしてしまおう。もちろん -t 0 でもいいけど、、いらないだろう。どうも ident らしいし。
というわけで、ぼくは -HRDl0 が定番オプションだと思ってることもあるので
とりあえず tcpserver 経由の -R オプションつきで起動してなければつけてもらうことに。
ついててこの現象が起こることはないと思われる。
さてどうなるかな。
・・・・と、もし tcpdump, wireshark を使わない、という条件で調べることになったら、どうやるのがいいんだろう？とふと思った。クライアントからは困難か。
cvs がもっさりしている(update やら checkout が始まるのに時間がかかる)
2ヶ月まえくらいから発生していた(らしい)
制限事項:
cvs のサーバには ssh ログインすることはできない
緊急ではなかったけど、放置しておくのもなんだかな、、と思ったので調べた。上記制限事項により、クライアント側からのみ、の調査に留まる。
方法:
tcpdump
wireshark
メモしてなかったけど、Mac OS X のターミナルでだいたい以下のように実行、、
$ sudo tcpdump -n -x -l -v -w ~/Desktop/cvs.tcpdump port 2401
しつつ、cvs checkoutやらupdate を実行して採取した。
ふむ、、、おそい。たしかにおそい。ためしに3回採取し、wireshark で解析。
するとすぐ目についたのが、
「26秒の待ち」。3回とも一様に待ちが発生している。
サーバには入れないので、これを手がかりに調査 & 社内のネットワークのプロに聞く。
すると、、某アプライアンス機器が弾いているという。
しかし26秒てなんだ、、と思って調べていると、 どうも ucspi-tcp パッケージ の tcpserver プログラム が怪しいことに気づく。
http://cr.yp.to/ucspi-tcp/tcpserver.html より
# -t n: Give up on the $TCPREMOTEINFO connection attempt after n seconds. Default: 26.
「タイムアウト」の時間が 26秒なので、タイムアウトする以前に、機能自体を無効にしてしまおう。もちろん -t 0 でもいいけど、、いらないだろう。どうも ident らしいし。
というわけで、ぼくは -HRDl0 が定番オプションだと思ってることもあるので
とりあえず tcpserver 経由の -R オプションつきで起動してなければつけてもらうことに。
ついててこの現象が起こることはないと思われる。
さてどうなるかな。
・・・・と、もし tcpdump, wireshark を使わない、という条件で調べることになったら、どうやるのがいいんだろう？とふと思った。クライアントからは困難か。
登録:
投稿 (Atom)