Bug 1254327

dnf-0.6.4-5.fc21.noarch

Attempting to do a manual "dnf update" gave the following message then stalled:

Waiting for process with pid 20324 to finish.

That process was the periodic makecache:

  PID TTY      STAT   TIME COMMAND
20324 ?        SNs    0:25 /usr/bin/python -OO /usr/bin/dnf -v makecache timer

stracing it:

Process 20324 attached
select(41, [38 39 40], [], [], {0, 32573}) = 0 (Timeout)
poll([{fd=38, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
poll([{fd=39, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
poll([{fd=40, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
select(41, [38 39 40], [], [], {1, 0})  = 0 (Timeout)
poll([{fd=38, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
poll([{fd=39, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
poll([{fd=40, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
select(41, [38 39 40], [], [], {1, 0})  = 0 (Timeout)
[...]

Those fds are:

lrwx------ 1 root root 64 Aug 15 03:33 40 -> socket:[12259455]
lrwx------ 1 root root 64 Aug 15 03:33 39 -> socket:[12259454]
lrwx------ 1 root root 64 Aug 15 03:33 38 -> socket:[12259453]

tcp6       0      0 <...>:44827 2001:67c:1220:e100::93e5:390:80 ESTABLISHED 0          12259455   20324/python        
tcp6       0      0 <...>:44825 2001:67c:1220:e100::93e5:390:80 ESTABLISHED 0          12259453   20324/python        
tcp6       0      0 <...>:44826 2001:67c:1220:e100::93e5:390:80 ESTABLISHED 0          12259454   20324/python       

The remote host resolves to mirror.cis.vutbr.cz.

This was at 2015-08-17 18:10, so it looks like it's been in that state for over 2.5 days. Given that it's reading from port 80 I guess it's send a HTTP request and is waiting for a response.

Either the remote server is just sitting there doing nothing, or due to some network glitch the remote end has gone away but we never received a FIN or RST. When that happens, because in the absence of SO_KEEPALIVE a TCP receiver doesn't *require* any packets to be received, unlike a TCP sender which must receive a timely ACK or it will abort the connection, a receiver that missed the FIN/RST can hang indefinitely unless it implements some sort of timeout of its own.

(Or enables SO_KEEPALIVE on the socket, though the default timeout on that is still a little over 2 hours, which is a bit high for this kind of thing.)

I recovered this with "systemctl stop dnf-makecache.service", but I'd expect some reasonable kind of timeout to deal with duff mirrors and network glitches alike.

(Err, just noticed as well: why poll() all the fds individually if select() on them didn't return? The answer's really not likely to have changed...)