2

I have a fairly simple little script. Basically, it performs ping over a given domain. It is like this:

ping -c2 $1 | head -n4 

And it prints out for example:

PING google.com (172.217.17.206): 56 data bytes
64 bytes from 172.217.17.206: icmp_seq=0 ttl=55 time=2.474 ms
64 bytes from 172.217.17.206: icmp_seq=1 ttl=55 time=2.668 ms

which is okay for me.

But for example like you know sometimes the ping command does not return any response from the ICMP request. Like for example:

ping intel.com
PING intel.com (13.91.95.74): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
--- intel.com ping statistics ---

And when this happens the script stuck for several seconds and then it resumes on its way. I'm trying to think of a way when this happens to just skip it and just proceed down. I actually not sure if it is possible at all. I was thinking at first to pipe it to grep for 'Request timeout' or to put the result in a variable and then cat | grep the variable.

Can someone think of a way for this and is it possible at all to just skip the execution when it hits Request timeout?

1

If you don't want it to be stuck for "several seconds" when a server fails to respond, add a timeout using the -W option. For example:

ping -c2 -W2 "$1"

-W2 sets a two-second time. Change the limit to fit your needs.

Aside

When referencing shell variables, like $1, always put them in double-quotes, like "$1", unless you explicitly know about and want word splitting and pathname expansion.

Documentation

From man ping:

-W timeout
Time to wait for a response, in seconds. The option affects only timeout in absence of any responses, otherwise ping waits for two RTTs.

  • Thank you. This should work for me. – Miro Jul 23 at 5:52
1

@John1024's answer is spot-on for Linux distributions. Since your question is not operating system-specific, I'll include a BSD solution.

BSD's ping command (also Mac OS X) has more granularity in some of its timing parameters. Most network connections have round-trip times well under one second. Indeed, many connections have an RTT of less than one millisecond. FreeBSD's man page for ping specifies that the -W option accepts an argument in units of milliseconds:

-W waittime

Time in milliseconds to wait for a reply for each packet sent. If a reply arrives later, the packet is not printed as replied, but considered as replied when calculating statistics.

The equivalent command using FreeBSD's ping then is:

ping -c2 -W2000 "$1"

The higher resolution of FreeBSD's -W parameter permits one to supply a -W value closer to the actual RTT that is expected.

Suppose a host testhost is known to be nominally 75 milliseconds away, round-trip. A -W value of 80 will yield:

jimsdesk : 14:45:58 /root# ping -W80 -c2 testhost
PING testhost (10.111.33.21): 56 data bytes
64 bytes from 10.111.33.21: icmp_seq=0 ttl=240 time=74.385 ms
64 bytes from 10.111.33.21: icmp_seq=1 ttl=240 time=74.478 ms

--- testhost ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 74.385/74.431/74.478/0.046 ms

A smaller -W value of 50 produces:

# ping -W50 -c2 testhost
PING testhost (10.111.33.21): 56 data bytes

--- testhost ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss, 2 packets out of wait time
round-trip min/avg/max/stddev = 74.466/74.538/74.611/0.073 ms

Suppose another host testhost2 is much closer, typically less than 4 milliseconds away. We'll specify a tighter -W tolerance of 4 milliseconds. Let's also increase -c to sample a larger number of packet trip times:

# ping -c10 -W4 testhost2
PING testhost2 (10.216.177.146): 56 data bytes
64 bytes from 10.216.177.146: icmp_seq=0 ttl=59 time=3.730 ms
64 bytes from 10.216.177.146: icmp_seq=1 ttl=59 time=3.899 ms
64 bytes from 10.216.177.146: icmp_seq=2 ttl=59 time=3.949 ms
64 bytes from 10.216.177.146: icmp_seq=3 ttl=59 time=3.668 ms
64 bytes from 10.216.177.146: icmp_seq=4 ttl=59 time=3.881 ms
64 bytes from 10.216.177.146: icmp_seq=5 ttl=59 time=3.725 ms
64 bytes from 10.216.177.146: icmp_seq=6 ttl=59 time=3.826 ms
64 bytes from 10.216.177.146: icmp_seq=8 ttl=59 time=3.726 ms
64 bytes from 10.216.177.146: icmp_seq=9 ttl=59 time=3.728 ms

--- testhost2 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss, 1 packets out of wait time
round-trip min/avg/max/stddev = 3.668/3.867/4.539/0.241 ms

The output above shows that nine of the ten packets made the round trip in 4 milliseconds or less, but one (seq 7) did not.

Ratcheting down even further, a lot of LAN RTTs are just under a millisecond, but not always. Running ping -c100 -W1 10.10.1.1 on a local network yielded:

...
--- 10.10.1.1 ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss, 10 packets out of wait time
round-trip min/avg/max/stddev = 0.664/1.081/18.547/1.898 ms

90 out of 100 packets returned in less than a millisecond, but the other 10 did not.

The localhost interface is a sub-millisecond round-trip on most computers. Unfortunately, FreeBSD's ping does not accept decimal values for -W:

# ping -c3 -W1 localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.020 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.018 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.020 ms

--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.018/0.019/0.020/0.001 ms

# ping -c3 -W.999 localhost
PING localhost (127.0.0.1): 56 data bytes

--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss, 3 packets out of wait time
round-trip min/avg/max/stddev = 0.020/0.022/0.025/0.002 ms

It would appear that a -W value of .999 is parsed as 0.

  • I don't have access to a BSD box so thanks for including the BSD info. – John1024 Aug 2 at 4:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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