[systemd-devel] The best way to deal with a deamon with two binary options

[Luis R. Rodriguez]

Hey folks,

Xen systemd support with active sockets and sd_notify() is under way,
we're in what seems to be the final rounds of patch review. One of the
last items we are reviewing is how to best deal with a deamon that has
two binary options for the daemon. They share the same arguments and
in order to support legacy init we have a sysconfig/default
configuration file with options. I realize the expressed position on
sysconfig/default directory [0] but since we wish to upkeep and share
with legacy init some behavior it seems best to use EnvironmentFile
for that sysconfig/default file for now. We have two possible deamons:
one written in C who's binary is called xenstored, and another one
written in Ocaml, oxenstored.At boot up one or the other can run, it
doesn't matter which one, and we require a reboot to change daemons,
we can't stop the service. The old legacy init can replace the binary
through an environment variable, for systemd we don't allow variables
for the ExecStart so this won't work there.

As per discussions at the LF Linux collaboration with Brandon one way
to support this in systemd is to provide separate service unit files
for both binaries, and provide a target unit file. System dependencies
would then depend on the target, not the service files. Switching
between binaries then would require manual intervention by the system
administrator, disable one, enable the other. These service unit files
would be mutually exclusive however. In order to maintain
compatibility with the legacy init approach however another
possibility we're not reviewing is the launcher concept which would
simply getenv() and execve() the appropriate daemon. We'd rename for
example the C version of xenstored to cxenstored, the Ocaml to
oxenstored, and the launcher would take up the general xenstored. The
benefit of this approach is we'd maintain one service unit file, and
the flipping of the daemons would consist of a simple edit on a
configuration file.

Would like feedback on this type of situation and recommendations as
to the best way to provide support for this type of situation. Any
other ideas are course always welcomed.

[0] http://0pointer.de/blog/projects/on-etc-sysinit.htm

  Luis