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

[Lennart Poettering]

On Thu, 22.05.14 11:17, Luis R. Rodriguez (mcgrof at do-not-panic.com) wrote:

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

Another option is to have two unit files and then one alias
(i.e. symlink) that points to one or another. Let's say you have two
implementations foo.service and bar.service, then place this in both:

[Install]
Alias=waldo.service

THis way you cannot enable both at the same time, as the symlink can
only point to one of them, and systemctl install will complain about
that... (unless --force) is used.

Lennart

-- 
Lennart Poettering, Red Hat