With iputils-20020124-2, "ping -c -1 unreachable-host" hangs forever. This is new behavior and certainly not backward-compatible (e.g., if it is used in a script to determine whether a host is accessible). Furthermore, watch what happens when I attempt to deal with this by running "ping -c -1 -w 5 unreachable-host": PING jik-vmware.kamens.brookline.ma.us (192.168.0.3) from 192.168.0.1 : 56(84) bytes of data. From jik (192.168.0.1) icmp_seq=1 Destination Host Unreachable From jik (192.168.0.1) icmp_seq=2 Destination Host Unreachable From jik (192.168.0.1) icmp_seq=3 Destination Host Unreachable --- jik-vmware.kamens.brookline.ma.us ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% loss, time 2010ms , pipe 3 There's two different issues here. First of all, why did it send three packages when I told it to send only one, and second, what does ", pipe 3" at the end mean?
Excerp from the manpage: -w deadline Specify a timeout, in seconds, before ping exits regardless of how many packets have been sent or received. In this case ping does not stop after count packet are sent, it waits either for deadline expire or until count probes are answered or for some error notification from network. So if you don't specify a timeout ping will wait if you do a -c 1 (not -c -1 btw., but i guess that was a typo). So this is not a bug but defined behaviour. Also i can't reproduce your 2nd problem, so i'm closing this bug as NOTABUG. Read ya, Phil
In the first place, the fact that the new behavior is documented does not, in my opinion, change the fact that it is a bug. It is an unnecessary, incompatible change to the program which adds no new functionality. If they want to make it possible for people to specify "-c" and have it wait forever, then they should allow people to specify "-w 0" or "-w -1" or something when they specify "-c"; absent such an argument, the old behavior should be preserved. Otherwise, all kinds of things are going to break, as one of my scripts did the minute I installed this "improved" version of ping -- using ping with a low "-c" argument is a very common idiom for checking whether a host is up. Second, even if you're going to leave the new behavior in place, at the very least it needs to be documented in the release notes for the next Red Hat release. Has it been? Third, I did not make up the behavior I reported with "pipe 3" showing up at the end of the output. It even shows up in the output of "strace ping -c 1 -w 5 192.168.0.6": # strace -o /tmp/strace.out ping -c 1 -w 5 192.168.0.6 PING 192.168.0.6 (192.168.0.6) from 192.168.0.1 : 56(84) bytes of data. From 192.168.0.1 icmp_seq=1 Destination Host Unreachable From 192.168.0.1 icmp_seq=2 Destination Host Unreachable From 192.168.0.1 icmp_seq=3 Destination Host Unreachable --- 192.168.0.6 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% loss, time 2014ms , pipe 3 # tail -3 /tmp/strace.out write(1, ", pipe 3\n", 9) = 9 munmap(0x40013000, 4096) = 0 _exit(1) = ? # With which version of iputils did you attempt to duplicate the problem?
OK, again to your 2 points: 1) The 'old' behaviour was to wait 10 seconds for the replys. I will revert the new behaviour of ping to that one despite the different description on the manpage as your argument about breaking scripts weights a lot more than a wrong description. Nonetheless are scripts by definition broken that rely on a feature that is actually documentend differently. 2) The latest ping of the iputils package now allows to 'queue' up packages, which they call pipes. Thats where the 'pipe 3' comes from in your output as ping actually queued 3 packages to the destination. But i agree, it should have sent only 1 package (as told), not 3. Looking into it. Read ya, Phil
*** Bug 66156 has been marked as a duplicate of this bug. ***
OK, i've just verified that in the latest version of the iputils package this behaviour now works again as exepcted. that is, ping -c 1 unreachable-host returns after 10 seconds and the -w option allows one to change the time in seconds to wait for the timeout. Also, the pipe output doesn't appear anymore. Read ya, Phil