web-dev-qa-db-ja.com

ICMPホストに到達できないため、Linuxpingコマンドが早期に終了します

自動化されたスクリプトは、マシン上でshutdown -r nowを実行し、30秒の遅延の後、pingを使用してマシンがいつ使用可能かを判断します。最近、OSをCentos5からOracleLinux 6に切り替えたところ、pingの動作が変更されていることがわかりました。

カウント（-c10）、期限（-w360）、遅延（-W1）の両方でpingを使用します。これは、マシンからの10回の正常な応答を最大5分間待機する必要があります。

自分のマシンが30秒後にDestination Host Unreachableメッセージを生成し、3つのエラーの後にpingが終了するのを観察しました。私の希望する締め切り値のかなり前。例えば。 〜37秒後に終了する例：

[cs@bst1 ~]# time ping -c10 -w360 -W1 hostother; echo $?
PING hostother (10.210.51.155) 56(84) bytes of data.
From bst1 (10.210.51.139) icmp_seq=36 Destination Host Unreachable
From bst1 (10.210.51.139) icmp_seq=37 Destination Host Unreachable
From bst1 (10.210.51.139) icmp_seq=38 Destination Host Unreachable

--- hostother ping statistics ---
38 packets transmitted, 0 received, +3 errors, 100% packet loss, time 37008ms
pipe 3

real    0m37.010s
user    0m0.001s
sys     0m0.000s
1

これはman pingと競合しているようです：

Pingが応答パケットをまったく受信しない場合は、コード1で終了します。パケット数と期限の両方が指定されていて、期限が到来するまでに受信されたパケット数より少ない場合は、コード1で終了します。その他のエラーでは、コード2で終了します。それ以外の場合は、コード0で終了します。これにより、終了コードを使用して、ホストが生きているかどうかを確認できます。

1）ICMPエラーが発生した場合のpingの動作は、マニュアルページと一致していますか？エラー状態では、戻りコードは2になるはずです。

2）自分のマシンがこれらのDestination Host Unreachableメッセージでジャンプするのを防ぐことは可能ですか？

Pingを数回再実行すると、最終的にホストが認識され、正常に終了します（リターンコード0）。

linuxpingicmp
5
shuckc

タイムアウトをpingから浸透させ、代わりにtimeoutコマンドを使用することをお勧めします（coreutilsの一部）：

timeout 300s bash -c "until ping -c10 hostother; do false; done"

コマンドがタイムアウトした場合、戻りコードとして124を取得します。例えば5分間に10回の連続pingで成功しなかった場合、および pingが成功した場合はすぐに成功します。

私はこれが本当に質問に答えないことを知っています（私はpingのマニュアルページが明確ではないことを認めます）が、うまくいけばあなたの当面の問題を解決します。

3
Patrice Levesque

1）はい、PINGの動作は一貫しています。 「宛先ホストに到達できません」にはさまざまな意味がありますが、そのうちの1つは「このホストにはLAN上にあることを示すアドレスがありますが、ARP要求に応答せず、有効なARPキャッシュがありませんそのエントリ "。

これが私のLANで何かをPINGし、ARPキャッシュエントリがないことを示しています。

[me@risby]$ ping 192.168.3.244
PING 192.168.3.244 (192.168.3.244) 56(84) bytes of data.
From 192.168.3.11 icmp_seq=1 Destination Host Unreachable
From 192.168.3.11 icmp_seq=2 Destination Host Unreachable
From 192.168.3.11 icmp_seq=3 Destination Host Unreachable
[...]
[me@risby]$ arp -a -n|grep 244
? (192.168.3.244) at <incomplete> on p1p1

応答パケットが受信されないのは事実であるため、PINGはエラー2を生成していません。これがPINGの問題ではないことも事実です。カーネルにicmpecho-r​​equestsを送信するように要求しましたが、カーネルは送信できないことを示しています。エラー2の例を次に示します。つまり、「I、PING、単にこれらの指示を実行できません。ボールを落としました "：

[me@risby]$ ping -c 3 192.168.3.999
ping: unknown Host 192.168.3.999
[me@risby]$ echo $?
2

2）いいえ。

他の人が親密になっているように、ICMP-echo-r​​equest-unresponseとは対照的に、ホストがダウンしているかどうかをテストするための間違った方法を選択しました。

1
MadHatter