[systemd-devel] Assertion failed in systemd v16

[Alexander E. Patrakov]

18.01.2011 04:14, Lennart Poettering пишет:
> On Mon, 10.01.11 15:11, Alexander E. Patrakov (patrakov at 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