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? > 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. > ExecReload=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf > ExecReload=/bin/kill -INT $MAINPID 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) > ExecReload=/bin/sleep 1 Evil! What's this for? > ExecReload=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf > StandardOutput=syslog > StandardError=syslog If you don't set StandardError explicitly it will be implicitly set to the same value as StandardOutput. In most cases it is hence sufficient to set only StandardOutput=. > > [Install] > WantedBy=multi-user.target > WantedBy=http-daemon.target > > Here is what happened when I tried to reload lighttpd while looking > with strace whan systemd is doing: > > [ 3639.047649] systemd[1]: Assertion 's->control_command_id == > SERVICE_EXEC_START' failed at src/service.c:2184, function > service_run_next_main(). Aborting. > [ 3639.052182] systemd[1]: Caught <ABRT>, dumped core as pid 6045. > [ 3639.052376] systemd[1]: Freezing execution. Ouch. This definitely needs to be fixed. > Also, $MAINPID handling seems to be unreliable - e.g., systemctl > stop lighttpd.service works correctly only while systemd is being > straced. Replacing /bin/kill -INT $MAINPID with killall -INT > $MAINPID removed both the unreliability of $MAINPID and the > assertion failure. So I guess that both bugs are somehow related to > my usage of $MAINPID. Yeah, MAINPID cannot really change during runtime right now. But I see no reason why we shouldn't make it possible to have a dynamically changing main PID to deal with lighthttpd here. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel