Date: Mon, 26 Dec 2022 14:13:29 -0700 From: "Nathan Huff" <nhuff@acm.org> To: freebsd-hackers@freebsd.org Subject: Fwd: Re: daemon(8) exit behavior Message-ID: <679d90a3-2b6b-4b9d-ab75-44558d93f916@app.fastmail.com>
next in thread | raw e-mail | index | archive | help
--8cf3b13f4f3447a0bf3fd6291bddccec
Content-Type: text/plain
Alan Somers <asomers@freebsd.org> writes:
>
> Do you mean SIGTERM instead of SIGHUP?
>
Yes I meant SIGTERM not SIGHUP.
>
> 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.
>
That is basically what my modification does. The delay really just
sends SIGKILL to the supervised process after the delay and waits for it
to die. The delay just gives the supervised process time to gracefully
shutdown before trying to more aggressively kill it.
>
> Waiting indefinitely is probably the best thing that we can do if a
> SIGKILLed process doesn't exit.
>
That is my opinion, but it isn't the current behavior so I figured
others might have a different opinion.
>>
>> --
>> Nathan Huff
>>
--8cf3b13f4f3447a0bf3fd6291bddccec
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>Alan Somers <=
;<a href=3D"mailto:asomers@freebsd.org">asomers@freebsd.org</a>> writ=
es:<br></div><div type=3D"cite" id=3D"qt" style=3D""><div><br></div><div=
>><br></div><div>> Do you mean SIGTERM instead of SIGHUP?<br></div=
><div>><br></div><div><br></div><div>Yes I meant SIGTERM not SIGHUP.<=
br></div><div><br></div><div>><br></div><div>> Instead of delaying=
for a fixed number of seconds, what if daemon were<br></div><div>> j=
ust to waitpid for the child after signaling it? That would preven=
t<br></div><div>> a command like "service foo restart" from starting =
a new instance of<br></div><div>> the daemon. But if the actual=
server process is still running, then<br></div><div>> that behavior =
is probably desirable.<br></div><div>><br></div><div><br></div><div>T=
hat is basically what my modification does. The delay really just<=
br></div><div>sends SIGKILL to the supervised process after the delay an=
d waits for it<br></div><div>to die. The delay just gives the supervised=
process time to gracefully<br></div><div>shutdown before trying to more=
aggressively kill it.<br></div><div><br></div><div>><br></div><div>&=
gt; Waiting indefinitely is probably the best thing that we can do if a<=
br></div><div>> SIGKILLed process doesn't exit.<br></div><div>><br=
></div><div><br></div><div>That is my opinion, but it isn't the current =
behavior so I figured<br></div><div>others might have a different opinio=
n.<br></div><div><br></div><div>>><br></div><div>>> --<br></=
div><div>>> Nathan Huff<br></div><div>>><br></div><div><br><=
/div></div><div><br></div></body></html>
--8cf3b13f4f3447a0bf3fd6291bddccec--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?679d90a3-2b6b-4b9d-ab75-44558d93f916>