Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

An automated script runs shutdown -r now on a machine, and after a 30s delay, uses ping to determine when the machine is available. I've recently switched the OS from Centos 5 to Oracle Linux 6 and found the behaviour of ping has changed.

I use ping with both a count (-c10), deadline (-w360) and delay (-W1) which should wait up to five minutes for ten successful replies from the machine.

I observe my own machine generating Destination Host Unreachable messages after 30 seconds that cause ping to exit after 3 errors ie. well before my desired deadline value. E.g. example exiting after ~37 seconds:

[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

This seems to conflict with man ping:

If ping does not receive any reply packets at all it will exit with code 1. If a packet count and deadline are both specified, and fewer than count packets are received by the time the deadline has arrived, it will also exit with code 1. On other error it exits with code 2. Otherwise it exits with code 0. This makes it possible to use the exit code to see if a host is alive or not.

1) Is the behaviour of ping in the face of ICMP errors consistent with the man page? It seems the return code should be 2 under error conditions.

2) Is it possible to prevent my own machine from jumping in with these Destination Host Unreachable messages?

If I re-run ping a few times, it eventually sees the host and exits cleanly (return code 0).

share|improve this question
1  
Ping isn't a good way to test that a server is available, all it really does is test that the server will respond to ping. Better to test that you server will respond to requests for whatever service it it is providing. –  Iain May 26 '13 at 7:38
add comment

2 Answers

up vote 1 down vote accepted

I suggest you percolate the timeout away from the ping and use the timeout command instead (part of coreutils):

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

You'll get 124 as return code if the command timed out; e.g. if it could not succeed in 10 consecutive pings in 5 minutes, and 0 if the ping succeeded, as soon as it happens.

I know this does not really answer the question (I admit the ping man page is not crystal clear) but hopefully solves your immediate issue.

share|improve this answer
    
Accepting this - a workaround is actually what I needed even if not what I asked for! –  shuckc May 30 '13 at 13:47
add comment

1) Yes, the behaviour of PING is consistent. "Destination host unreachable" can mean a number of things, but one of them is "this host has an address that indicates it's on my LAN, but it does not respond to ARP requests, and I have no valid ARP cache entry for it".

Here's me PINGing something on my LAN, and showing that it has no ARP cache entry:

[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 isn't producing error 2 because it's true that no reply packets are received. It's also true this isn't PING's problem; it has asked the kernel to send icmp echo-requests, and the kernel has indicated that it can't do so. Here's an example of error 2, ie, "I, PING, simply cannot carry out those instructions; I have dropped the ball":

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

2) No.

As others have intimated ,you've picked the wrong way to test for a host being down, as opposed to ICMP-echo-request-unresponsive.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.