Date: Mon, 26 Dec 2022 10:34:51 -0700 From: Alan Somers <asomers@freebsd.org> To: Nathan Huff <nhuff@acm.org> Cc: freebsd-hackers@freebsd.org Subject: Re: daemon(8) exit behavior Message-ID: <CAOtMX2g9z1X1ObBLxTgn_-iL9hPuHmttVyTZSA77twuNxsHCxg@mail.gmail.com> In-Reply-To: <86tu1i6q2s.fsf@enyo.nrhuff.com> References: <86tu1i6q2s.fsf@enyo.nrhuff.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 26, 2022 at 10:19 AM Nathan Huff <nhuff@acm.org> wrote: > > > 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. Do you mean SIGTERM instead of SIGHUP? > > 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. Instead of delaying for a fixed number of seconds, what if daemon were just to waitpid for the child after signaling it? That would prevent a command like "service foo restart" from starting a new instance of the daemon. But if the actual server process is still running, then that behavior is probably desirable. > > 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. Waiting indefinitely is probably the best thing that we can do if a SIGKILLed process doesn't exit. > > -- > Nathan Huff >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2g9z1X1ObBLxTgn_-iL9hPuHmttVyTZSA77twuNxsHCxg>