[systemd-devel] lighttp unit - graceful reload of configfiles by sending signal to $MAINPID

[Lennart Poettering]

On Mon, 10.01.11 18:49, Marius Tolzmann (tolzmann at molgen.mpg.de) wrote:

> and why do you explicitly not use the -D option and let systemd do
> all the forking stuff for you..? you could get rid off the Type=
> PIDFile= lines.. i also removed StandardError=syslog which seems to
> be redundant here..

Generally it is advisable to let systemd handle the forking, but I guess
if the daemon is weird as lighthttpd is then it is a better idea to
use the internally forking and make systemd load the PID file.

> 
> would this work? or isn't restart intended to be used for those kind
> of things?
> 
> SignalStop=SIGINT and SignalReload=SIGINT or something similar may
> be a nice shortcut for doing those kind of things.. Since
> SignalReload=SIGHUP seems to be a way how it is done most of the
> time?

As mentioned elsewhere I am not a big fan of using signals like this,
since signal delivery is async, and the stop/reload operations should be
synchronous, i.e. if you issue "systemctl reload foo.service" you should
be able to rely that the reloading is complete if the command following
this line is executed.

> Another question: Doesn't the default KillMode=control-group would
> send a SIGTERM to the remaining processes of this service
> immediately after the ExecStop= returns and so break the idea behind
> a graceful shutdown where the main-process exits and all running
> http-requests will be finished? (Or is there also a delay of
> TimeoutSec= between ExecStop= and the first SIGTERM?)

No, there isn no such delay.

systemd will send the SIGTERM to the processes remaining in the cgroup
only. If the the stop command of the service didn't do its work (or
wasn't configured) it will kill everything that is left.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.