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... systemd expects that binaries forked off with ExecStart= (if you use Type=forking) or ExecReload= return only after the new daemon is fully up and the PID file is written. THis isn't actually any different from sysv except that sysv traditionally has been a bit more forgiving here, since daemons where never monitored... You need to have some synchronization logic in place that lets the ExecStart= or ExecReload= binary know when the daemon process is done with what it wants to do, and only then exits. A pipe of some kinda should work fine, or a unix socket, or something like that... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
