Philipp Kern <pkern@debian.org> (2015-02-18): > On Tue, Feb 10, 2015 at 09:22:25AM +0100, Philipp Kern wrote: > > On Sun, Feb 08, 2015 at 04:21:25PM +0100, Philipp Kern wrote: > > > On the other hand it also seems wrong for di_exec_shell_log to continue > > > after the invoked binary exited. I suspect that'd mean ppoll() and > > > proper signal handling, but I'm at a loss right now how to do that > > > properly in C. Maybe that's the right place to fix it in the meantime. > > > > I guess signalfd would make this rather neat, but it's not available > > on FreeBSD. :( > > > > The alternative would be to overwrite the SIGCHLD signal handler > > regardless of what has been set before and handle the signal in the > > library. > > So now I guess the question is if we revert the change that broke it: > > Don't kill_dhcp_client without reason (Closes: #757711, #757988) > > Do not kill_dhcp_client after setting the hostname and > domain, otherwise Linux udhcpc will stop renewing its lease, and > on other platforms dhclient will de-configure the network interface > (Closes: #757711, #757988) > > At this point kFreeBSD is no longer a release architecture and the other > platform using dhclient is Ubuntu. GNU/kFreeBSD people are (AFAICT) going to try and get an unofficial release out, so pushing a regression in their way doesn't look too good to me. Maybe using an #ifdef here to avoid killing the DHCP client on kfreebsd, and reinstating the previous codepath on linux would be an acceptable compromise until some evolved signal/process handling pops up (during the stretch release cycle)? (No idea about hurd; anyway, adding both porter lists to Cc.) Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature