Date: Mon, 26 Dec 2022 10:18:51 -0700 From: Nathan Huff <nhuff@acm.org> To: freebsd-hackers@freebsd.org Subject: daemon(8) exit behavior Message-ID: <86tu1i6q2s.fsf@enyo.nrhuff.com>
next in thread | raw e-mail | index | archive | help
The current behavior for the daemon command when it receives the HUP signal and it is supervising a process is to send a HUP signal to the supervised process and then exit immediately. According to the source comments this is the intended behavior. The issue I have run into with this behavior is that when the daemon process is when writing the supervised processes stdout/stderr to syslog or an output file you can lose any log messages that the supervised process outputs during its shutdown process. I created a small modification to the daemon process that allows setting a shutdown delay that will send HUP to the supervised process then continues to read the process output for up to delay seconds and then sends the supervised process the KILL signal. This allows a window for the supervised process to gracefully shutdown and we can still log any messages created during that time period. A couple questions for the list. 1. Is there any interest in upstreaming this? 2. What should happen if the supervised process doesn't exit after the KILL signal is sent? Something has probably gone sideways somewhere if we end up here, but I have definitely seen cases where something is stuck with signals blocked. Currently my modification waits for the process to actually exit possibly indefinitely. I chose that because I don't think we should clean up PID files if the process is in fact still running, but I can see wanting the daemon process to exit even if the supervised process is still running as that is the current behavior and still the behavior if a shutdown delay is not specified in my modified version. -- Nathan Huff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86tu1i6q2s.fsf>