[systemd-devel] GuessMainPID=no required to make daemon reload work

[Alexander E. Patrakov]

05.05.2014 21:14, Lennart Poettering wrote:
> On Mon, 05.05.14 10:00, Gerd v. Egidy (lists at egidy.de) wrote:
>
>>> systemd will behave as expected: once your main process terminates it will
>>> re-read PID
>>> from this file (assuming that before dying your old process writes its
>>> child's PID) and set it as MAINPID for your service.
>>
>> Hmm. Currently it is done like this: the old daemon releases the lock on the
>> pidfile and terminates itself. The new daemon detects this and then writes it's
>> own pid to the pidfile and locks it.
>>
>> So there is a short time where the old daemon is already dead and the new one
>> hasn't written it's pid yet. Probably this is the problem. But I have to think
>> about a way to get the locking stuff right as I can't easily transfer the lock
>> over an exec.
>
> Generally, it's not a good idea to keep file locks for a longer period
> of time... YOu should really just take them while you write a file, and
> then release them, but not keep them forever...

Note that "man 7 daemon", which is a part of systemd, contains this 
paragraph:

> 12. In the daemon process, write the daemon PID (as returned by
> getpid()) to a PID file, for example /run/foobar.pid (for a
> hypothetical daemon "foobar") to ensure that the daemon cannot be
> started more than once. This must be implemented in race-free fashion
> so that the PID file is only updated when it is verified at the same
> time that the PID previously stored in the PID file no longer exists
> or belongs to a foreign process. Commonly, some kind of file locking
> is employed to implement this logic.

I guess that the text needs to be clarified, as currently it is a source 
of long-living locks on PID-files, with the associated vulnerabilities.

-- 
Alexander E. Patrakov