05.05.2014 21:14, Lennart Poettering wrote:
On Mon, 05.05.14 10:00, Gerd v. Egidy (li...@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
