[pkg-dhcp-devel] Bug#761850: dhclient problem caused by disconnected stderr socket

[Michael Paul]

I've encountered this too, and it looks like it's not a problem with 
dhclient itself.  It may not be NetworkManager either.  I suspect 
systemd, but I'm not sure.

Investigating with strace, I found that dhclient is terminating due to a 
SIGPIPE when trying to write its first line of output ("Internet Systems 
Consortium DHCP Client") to stderr.  Its /proc/self/fd shows that stderr 
is a socket:  the "2" link points to "socket:[15055]".  I thought the 
socket might be connected to NetworkManager, so I checked and found that 
actually NetworkManager's stderr is the same socket; both processes are 
sending their output to the same place.

However, it's not clear what the socket actually connects to. Figuring 
the number 15055 was an inode number of a Unix domain socket file, I ran 
"find / -inum 15055" as root, but didn't find anything.  I also did "ls 
-l /proc/*/fd/* | grep 15055", and the only hits were the stdout and 
stderr of the NetworkManager process.

After restarting NetworkManager, its stderr was a *different* socket 
(different number), and dhclient inherited that new socket and was able 
to run successfully.  But I did another search and couldn't find any 
socket files with the new inode number, nor any hits in /proc/*/fd 
besides the new NetworkManager and dhclient processes, so it's still 
unclear what's on the other end of the socket even when it's working.

I suspect systemd is involved since NetworkManager had the bad socket as 
its stderr, and stderr is typically provided by the parent process, and 
NetworkManager is started by systemd.  But without knowing what the 
socket connects to, it's hard to be sure.