'Twas brillig, and Brandon Black at 29/11/12 04:41 did gyre and gimble: > The daemon's "fast restart" code does all of the expensive startup > operations in the new daemon first (e.g. parsing large data input), then > signals the existing daemon to shut itself down, waits for it to release > its critical resources (e.g. sockets, pidfile), and finally takes over > those resources and finishes starting itself. Basically it's using the > overlap to avoid long service downtimes during that initial parsing > phase (and if that parsing fails, it leaves the old daemon running to boot).
You should likely look into socket activation. It won't give you all the features above it should mean that no connections are lost in that window. What I would probably recommend here is that you write a basic wrapper daemon (which itself can be socket activated, but that's beside the point really), that can accept a signal to trigger the reload. You could then signal this wrapper daemon in ExecReload (something like: "ExecReload=/usr/bin/kill -s SIGUSR1 $MAINPID"). It can then pass around the socket as needed to your real daemon. I think it's a basic design decision that ExecReload will not allow for an effective restart here. Reload != Restart after all. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
