18.01.2011 04:14, Lennart Poettering пишет:
On Mon, 10.01.11 15:11, Alexander E. Patrakov (patra...@gmail.com) wrote:
[Unit]
Description=Lighttpd Web Server
After=network.target
[Service]
Type=forking
EnvironmentFile=/etc/conf.d/lighttpd
PIDFile=/var/run/lighttpd.pid
ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf
Hmm, whiy is this necessary? I presumee starting the daemon will do an
implicit configuration check anyway, right? I mean, how could it load
the config without checking for its validity?
Indeed, my bad.
ExecStart=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
ExecStop=/bin/kill -INT $MAINPID
This is asynchronous. The stop operation is supposed to be synchronous
however, should not return before it finished.
This was modeled after the existing apache2 service file in gentoo
systemd overlay, which uses graceful asynchronous stop. If you delete
the ExecStop line, systemd will use SIGTERM (non-graceful stop) and
wait. That's probably what you want the stop operation to be. OTOH, like
it or not, too many existing services don't have any mechanism for
synchronous reload and use SIGHUP.
I think you should audit all existing service files in Gentoo systemd
overlay to ensure that I don't copy any more bad practice. See
http://git.overlays.gentoo.org/gitweb/?p=user/systemd.git;a=summary
As you noticed, this changes the PID, and systemd currently cannot
handle this.
We could however reload the PID file after a reload completed I
guess. (/me adds this to the todo list)
Well, there are cases (live update of nginx, see
http://wiki.nginx.org/NginxCommandLine#Upgrading_To_a_New_Binary_On_The_Fly)
where the main PID would change without the explicit "systemctl reload"
command. In the case of nginx, one can follow up the live update with a
dummy "systemctl reload", so I am not sure if it matters.
OTOH, maybe it would be better to evaluate the main PID lazily when it
is needed, instead of trying to enumerate all places where it can change
and reloading it there. But this way we will also hide all races caused
by bad PID file handling logic, so I am not sure.
--
Alexander E. Patrakov
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
