Re: daemon(8) exit behavior
- In reply to: Nathan Huff : "daemon(8) exit behavior"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 26 Dec 2022 17:34:51 UTC
On Mon, Dec 26, 2022 at 10:19 AM Nathan Huff <firstname.lastname@example.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 >