GNOME Bugzilla – Bug 735962
dhcp: DHCP client exits abnormally
Last modified: 2014-09-12 11:04:25 UTC
DHCP client exits abnormally when run by NetworkManager and thus the connection cannot be properly activated. The error can be triggered by restarting systemd-journald. After doing that, DHCP client will not start properly, but exits with: <info> (enp0s25): DHCPv4 client pid 13959 exited with status -1 <warn> DHCP client died abnormally
There is a report in debian for the issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758533 I have inspected the problem and found that dhclient was killed by signal 13, which is SIGPIPE. We should ignore this signal, because it has no use for us, and the default action for it is to terminate process. Actually, systemd also ignores SIGPIPE for its services, by default: http://cgit.freedesktop.org/systemd/systemd/commit/?id=353e12c2f4a9e96a47eb80b80d2ffb7bc1d44a1b Testcase: - start a NetworkManager service by systemd - activate an DHCP ethernet connection - sudo systemctl restart systemd-journald.service - reactive the ethernet connection (nmcli con up <my-eth>) - DHCP client is killed by SIGPIPE right after its startup: <info> (enp0s25): DHCPv4 client pid 13959 exited with status -1 <warn> DHCP client died abnormally
I have pushed a fix to jk/bgo735962-dhcp-sigpipe branch.
(In reply to comment #2) > I have pushed a fix to jk/bgo735962-dhcp-sigpipe branch. Hmm, I can't see that branch anywhere, could you re-push?
(In reply to comment #3) > (In reply to comment #2) > > I have pushed a fix to jk/bgo735962-dhcp-sigpipe branch. > > Hmm, I can't see that branch anywhere, could you re-push? Ah, sorry. It is there now.
Hm... doesn't this also mean that the dhclient messages will be lost, rather than ending up in the journal? OK, investigating a little bit more, it looks like no, because dhclient is redundantly logging everything to both stderr and to syslog, because we're passing "-d" to keep it from daemonizing, but that also turns on verbose mode. If we passed "-q" in addition to "-d", that would turn verbose mode off, and then it would only log to syslog, and so there'd be no problem. (Although, just to be safe, we should probably also spawn it with G_SPAWN_STDOUT_TO_DEV_NULL | G_SPAWN_STDERR_TO_DEV_NULL.
(In reply to comment #5) > Hm... doesn't this also mean that the dhclient messages will be lost, rather > than ending up in the journal? > > OK, investigating a little bit more, it looks like no, because dhclient is > redundantly logging everything to both stderr and to syslog, because we're > passing "-d" to keep it from daemonizing, but that also turns on verbose mode. > If we passed "-q" in addition to "-d", that would turn verbose mode off, and > then it would only log to syslog, and so there'd be no problem. (Although, just > to be safe, we should probably also spawn it with G_SPAWN_STDOUT_TO_DEV_NULL | > G_SPAWN_STDERR_TO_DEV_NULL. Done. Though I leave the SIGPIPE blocking there as it protects us from possible other unexpected SIGPIPEs.
Looks fine to me.
(In reply to comment #6) > > to be safe, we should probably also spawn it with G_SPAWN_STDOUT_TO_DEV_NULL | > > G_SPAWN_STDERR_TO_DEV_NULL. > > Done. Though I leave the SIGPIPE blocking there as it protects us from possible > other unexpected SIGPIPEs. Well, if stdout and stderr are both redirected to /dev/null, then dhclient could only get SIGPIPEs from fds that it opened itself, so it seems like we shouldn't be interfering with that.
(In reply to comment #8) > (In reply to comment #6) > > > to be safe, we should probably also spawn it with G_SPAWN_STDOUT_TO_DEV_NULL | > > > G_SPAWN_STDERR_TO_DEV_NULL. > > > > Done. Though I leave the SIGPIPE blocking there as it protects us from possible > > other unexpected SIGPIPEs. > > Well, if stdout and stderr are both redirected to /dev/null, then dhclient > could only get SIGPIPEs from fds that it opened itself, so it seems like we > shouldn't be interfering with that. OK, the redirections fix the bug. So I removed the SIGPIPE ignoring not to be paranoid. :-) Pushed to master: e47235b dhcp: log DHCP client exit status better b276696 dhcp: fix dhclient abnormal exit due to SIGPIPE (bgo #735962)