Bug 62125 - "ping -c 1 unreachable-host" hangs forever
"ping -c 1 unreachable-host" hangs forever
Status: CLOSED CURRENTRELEASE
Product: Red Hat Raw Hide
Classification: Retired
Component: iputils (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Aaron Brown
:
: 66156 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-27 13:57 EST by Jonathan Kamens
Modified: 2015-03-04 20:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-14 09:44:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jonathan Kamens 2002-03-27 13:57:56 EST
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?
Comment 1 Phil Knirsch 2002-03-28 11:42:11 EST
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
Comment 2 Jonathan Kamens 2002-03-31 20:48:27 EST
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?
Comment 3 Phil Knirsch 2002-04-05 07:01:02 EST
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
Comment 4 Phil Knirsch 2002-06-18 07:39:13 EDT
*** Bug 66156 has been marked as a duplicate of this bug. ***
Comment 5 Phil Knirsch 2003-05-14 09:44:45 EDT
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

Note You need to log in before you can comment on or make changes to this bug.