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 ( 56(84) bytes of data.
From bst1 ( icmp_seq=36 Destination Host Unreachable
From bst1 ( icmp_seq=37 Destination Host Unreachable
From bst1 ( 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

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).

  • 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.
    – user9517
    May 26, 2013 at 7:38

2 Answers 2


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.

  • 1
    Accepting this - a workaround is actually what I needed even if not what I asked for!
    – shuckc
    May 30, 2013 at 13:47

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
PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Host Unreachable
From icmp_seq=2 Destination Host Unreachable
From icmp_seq=3 Destination Host Unreachable
[me@risby]$ arp -a -n|grep 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
ping: unknown host
[me@risby]$ echo $?

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .