Re: bin/57952: dhcpcd(8) inexplicably terminated in the night

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/57952; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/57952: dhcpcd(8) inexplicably terminated in the night
Date: Fri, 23 Feb 2024 01:15:56 +0700

 As it happens, a few days ago, a friend of mine (not on any netbsd lists)
 had much the same thing happen - dhcpcd on a NetBSD 9.3 host simply
 vanished, without any log messages.
 
 In that case, a possible explanation was carrier being lost, and reappearing
 due to a shoddy connector (apparently wiggling the cable at the socket
 caused carrier to reappear) but no new address was acquired, after which
 upon looking, there was no dhcpcd in sight to obtain one (this would have
 been a v4 only installation - simply no v6 available).
 
 That cause is mere speculation - no question about the wonky cable causing
 carrier loss, but whether that had anything to do with dhcpcd's decision to
 vanish is mere speculation.
 
 At the time the setup there was using dhcpcd=NO in rc.conf, and "dhcp" in
 /etc/ifconfig.wm0, with -q in dhcpcd_flags (just the default setting).
 
 It has since been changed to dhcpcd=YES with debug enabled in dhcpcd.conf
 and no -q in dhcpcd_flags to increase the chances of there being something
 revealing in the logs if it happens again).
 
 I agree with this though:
 
    Preferably, dhcpcd would at least give a reason for each way that
    it does terminate.
 
 Regardless of what options are set, or not, if a daemon that should remain
 running needs to exit, it should always say why - even if that means keeping
 a parent around that does nothing except wait on the child (which does the
 work, owns the .pid file ...) so it can report exits due to a signal if
 one should happen, which the child itself cannot reasonably log.