Re: daemon(8) exit behavior

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
>