On 11/29/2012 04:41 AM, Brandon Black wrote:
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).
Which daemon is this ?
JBG
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
