こういうスクリプトを実行するとたまに悲しいことになります。
#!/bin/sh -x ping 192.168.0.1 & sleep 1.005 kill -INT %1
FreeBSD だと sleep の引数は小数点以下も有効なので。
ミリ秒の桁で発生頻度が変わりますが、うまく調整するとこうなります。
+ sleep 1.005 + ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=0.764 ms + kill -INT %1 --- 192.168.0.1 ping statistics --- 2 packets transmitted, 1 packets received, 50.0% packet loss round-trip min/avg/max/stddev = 0.764/0.764/0.764/0.000 ms
50% loss...oh...2個目を送ったのに帰ってくる前にタイムアウトしちゃったかぁ……
同系統の現象でこういうパターンも作れますね。
$ ping -t 1 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=118 time=5.834 ms --- 8.8.8.8 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 5.834/5.834/5.834/0.000 ms $ ping -t 1 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=118 time=6.168 ms --- 8.8.8.8 ping statistics --- 2 packets transmitted, 1 packets received, 50.0% packet loss round-trip min/avg/max/stddev = 6.168/6.168/6.168/0.000 ms
FreeBSD の ping は -t で所定時間後に終了するのですが、
宛先までの到達時間次第ではこんな風に。
実行するたびにランダムに（？）送れるパケットが 1 だったり 2 だったりして、 タイミング次第では 2 個目の応答は間に合わず……(´・ω・｀)
また別パターンだとこう。
$ timeout -s SIGINT 1.005 ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=0.843 ms --- 192.168.0.1 ping statistics --- 2 packets transmitted, 1 packets received, 50.0% packet loss round-trip min/avg/max/stddev = 0.843/0.843/0.843/0.000 ms
timeout コマンドでも冒頭の fork & kill と同等のことが発生しますね。
教訓としては、ping を指定時間で止めるのはやめましょうということですかね。
素直に -c 300 とかやるしかなさそうです。これだとぴったり 5 分にはなりませんが。
誰かぴったり 5 分間 ping を送る方法、知りませんかね？
