<br><div>Hi all,</div><div><br></div><div>  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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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).</div>
<div><br></div>