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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
