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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
