Skip site navigation (1)Skip section navigation (2)
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>