[systemd-devel] ExecRestart

[Brandon Black]

Hi all,

  I'm trying to write a systemd.service unit file for an existing
well-behaved daemon that's used to managing itself.  The daemon binary
doubles as its own controller for sysvinit-like command.  For example "foo
start" launches a new daemon. "foo stop" stops an existing instance of the
daemon.  Similarly for restart, condrestart, status, etc.  This makes
things very simple in the world of sysv-like init systems.  The
"initscript" just execs the daemon binary and passes on the user action
argument, and all of the tricky bits are well-managed within the daemon's
own code (pidfiles, sockets, logging, strange corner cases, timing issues,
etc).

I can't simply convert the daemon to expect all of systemd's nice features
and gut all of its self-management code, as it must still be portable to
non-systemd platforms where these features are handy.  For the most part
I've been able to successfully work around things, but lack of an
ExecRestart is one of my remaining hangups.

I certainly can publish a unit file without this, and restart would be
performed by ExecStop -> ExecStart.  However, the daemon has a bunch of
nice code to do a better restart than that, and I'd need an ExecRestart to
allow users to continue to take advantage of that.

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).

Is there some design reason that we can't have an ExecRestart command?
 Successful exit of that command would mean the old instance was killed
(which systemd could confirm), and that the restart command has launched a
new instance (which systemd can also figure out via PIDFile or
guessing/cgroup).  Failure exit of that command would mean the existing
daemon instance was left alone (and again, systemd could confirm that
state).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20121128/24ad4c1d/attachment.html>