Bug 677395

Works fine here.  Make sure you didn't block the signals.

Ok, it's pretty hard to trigger, but I can definitely trigger it *sometimes*:

130!bernie@giskard:~/src/fdo/xserver$ ping google.com
PING google.com (74.125.226.113) 56(84) bytes of data.
^C^C^C^C^C^C^C^C^C^C^C^C
^C^C^C
64 bytes from 74.125.226.113: icmp_req=1 ttl=55 time=16.8 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.859/16.859/16.859/0.000 ms

Do you have nscd enabled?

The backtrace has no reference to nscd at all.

(In reply to comment #3)
> The backtrace has no reference to nscd at all.

Is it just possible that my first ^C made the nscd codepath abort and return an error, so that __gethostbyaddr_r() continued with the in-process resolver?

Ok, now I can reproduce it at will:

 sudo killall -STOP nscd
 sudo ltrace -S  ping google.com

And this is what I get from ping:

[...]
getopt(2, 0x7fff5009bc28, "h?VQ:I:M:aUc:dfi:w:l:S:np:qrs:vL"...) = -1
inet_aton("google.com", 0x61a7c4)                = 0
idna_to_ascii_lz(0x7fff5009d7f4, 0x7fff5009b640, 0, 0, 0) = 0
gethostbyname("google.com" <unfinished ...>
SYS_getpid()                                     = 30330
SYS_open("/etc/resolv.conf", 0, 0666)            = 4
SYS_fstat(4, 0x7fff500992e0, 0x7fff500992e0, 2, 1) = 0
SYS_mmap(0, 4096, 3, 34, 0xffffffff)             = 0x7f1a56b17000
SYS_read(4, "search localnet office.fsf.org f"..., 4096) = 71
SYS_read(4, "", 4096)                            = 0
SYS_close(4)                                     = 0
SYS_munmap(0x7f1a56b17000, 4096)                 = 0
SYS_socket(1, 526337, 0, 0x3000481310, 0)        = 4
SYS_connect(4, 0x7fff5009b010, 110, 0x3000481310, 0) = 0
SYS_sendto(4, 0x7fff5009afd0, 18, 16384, 0)      = 18
SYS_poll(0x7fff5009b280, 1, 5000, 16384, 4

The process hangs right here, while talking to nscd, and became unkillable.

I was partially incorrect: in the above testcase, the process that would hang and become unresponsive to ^C was actually sudo, not ping.

At least now we know that it's not a problem specific to the resolver. Perhaps something odd happens while processes are talking with nscd?

Works fine here.

I've seen the same symptom today on an Ubuntu 8.04 LTS server machine which isn't running nscd.

This time I could background the ping process and trace what happens when I hit CTRL-C:

---------------------------------------------------------------
root@monolith:~# ping servent.gnu.org
PING servent.gnu.org (199.232.41.14) 56(84) bytes of data.

***** HERE I'VE BEEN HITTING CTRL^C REPEATEDLY *****

[1]+  Stopped                 ping servent.gnu.org
root@monolith:~# strace -p 27318
Process 27318 attached - interrupt to quit

Process 27318 detached

[1]+  Stopped                 ping servent.gnu.org
root@monolith:~# strace -p 27318 &
[2] 27325
root@monolith:~# Process 27318 attached - interrupt to quit

root@monolith:~# fg
ping servent.gnu.org
restart_syscall(<... resuming interrupted call ...>) = 0
poll([{fd=5, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
sendto(5, "\315\355\1\0\0\1\0\0\0\0\0\0\00214\00241\003232\003199"..., 44, MSG_NOSIGNAL, NULL, 0) = 44
poll(
[{fd=5, events=POLLIN}], 1, 5000)  = ? ERESTART_RESTARTBLOCK (To be restarted)


***** HERE I STARTED TO HIT CTRL^C AGAIN *****


--- SIGINT (Interrupt) @ 0 (0) ---
rt_sigreturn(0x2)                       = -1 EINTR (Interrupted system call)
poll([{fd=5, events=POLLIN}], 1, 2323)  = ? ERESTART_RESTARTBLOCK (To be restarted)
--- SIGINT (Interrupt) @ 0 (0) ---
rt_sigreturn(0x2)                       = -1 EINTR (Interrupted system call)
poll([{fd=5, events=POLLIN}], 1, 1196)  = ? ERESTART_RESTARTBLOCK (To be restarted)
--- SIGINT (Interrupt) @ 0 (0) ---
rt_sigreturn(0x2)                       = -1 EINTR (Interrupted system call)
poll([{fd=5, events=POLLIN}], 1, 620)   = ? ERESTART_RESTARTBLOCK (To be restarted)
--- SIGINT (Interrupt) @ 0 (0) ---
rt_sigreturn(0x2)                       = -1 EINTR (Interrupted system call)
poll([{fd=5, events=POLLIN}], 1, 203)   = 0
close(4)                                = 0
close(5)                                = 0
write(1, "64 bytes from 199.232.41.14: icm"..., 6064 bytes from 199.232.41.14: icmp_seq=1 ttl=53 time=37.0 ms
) = 60
write(1, "\n", 1
)                       = 1
write(1, "--- servent.gnu.org ping statist"..., 40--- servent.gnu.org ping statistics ---
) = 40
write(1, "1 packets transmitted, 1 receive"..., 601 packets transmitted, 1 received, 0% packet loss, time 0ms
) = 60
write(1, "rtt min/avg/max/mdev = 37.052/37"..., 53rtt min/avg/max/mdev = 37.052/37.052/37.052/0.000 ms
) = 53
exit_group(0)                           = ?
Process 27318 detached
[2]-  Done                    strace -p 27318
---------------------------------------------------------------

Unfortunately, the network problem got fixed and I couldn't reproduce it again. I would have been good to have a backtrace of the process.

Now we know the following things:

 * the bug is not Fedora specific
 * the bug is not nscd specific
 * the bug has not been introduced in libc recently (glibc 2.7 had it)

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I can't see any reason why gethostbyaddr or its relatives would be ignoring signals.  I guess the one additional test you could try would be ping -n which disables the reverse lookup.

I really think you need to look at your tty settings and other aspects of your system to ensure that the requested signals are actually being delivered.  I'm closing this as WORKSFORME as nobody else has been able to reproduce this problem.

(In reply to comment #10)
> I can't see any reason why gethostbyaddr or its relatives would be ignoring
> signals.  I guess the one additional test you could try would be ping -n which
> disables the reverse lookup.
> 
> I really think you need to look at your tty settings and other aspects of your
> system to ensure that the requested signals are actually being delivered.  I'm
> closing this as WORKSFORME as nobody else has been able to reproduce this
> problem.

Then this bug might have been fixed in recent versions of Fedora.

I'm still seeing the same behavior on my work laptop which runs Ubuntu Lucid: on network outages, ping and other programs get stuck on reverse lookups and can't be killed with ^C.