[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

PoC: cross-init-bridge



Hi there,

(CC Steve Langsek, since he's maintainer/developer (?) of Upstart.)
(I'm not on the debian-devel list, so please use reply to all.)

People, especially in the TC, have criticized that there are different
protocols for systemd and upstart to specify things such as
notifications and/or socket activation. Back before the voting there was
actually quite a discussion on whether init system A could be made to
support protocol of B and vice-versa. I think there are even bug reports
against both upstart and systemd because of this.

To solve this problem, I've created a small tool called
cross-init-bridge. Its goal is to translate readiness notifications /
socket activation from one init system to another. It currently supports
systemd <-> upstart (in both directions), although the lowest common
denominator is used (which for both features happens to be Upstart).

Code:
https://github.com/chris-se/cross-init-tools
(License: GPLv3+)
(See README file for details.)

There are still a few kinks to be worked out, and somebody needs to
review the code for security, but in principle it works, so one can
actually run systemd-enabled daemons (notify, socket activation) on top
of Upstart and vice-versa.



To put the whole thing into a bit of a big picture perspective:

Since Canonical has now decided that in the long term they will probably
switch to systemd, it does not seem unlikely that at some point Upstart
might not be relevant anymore. However, if that is to happen, that will
take place in the distant future, because of Canonical's LTS commitment.
In light of this, I think that tools for increasing compatibility
between init systems can be really helpful, even if it might only be for
a transitional period.

Also, systemd does not run on non-Linux ports and will most likely not
run on those anytime soon, if Debian wants to support those, they will
have to make due with another init system. Currently, the only
contenders for those ports are sysvinit and OpenRC. And for
compatibility reasons, even on Linux sysvinit will have to be supported
for quite a while now. But one of the main advantages of both systemd
and Upstart (and also OpenRC) is that the init definitions (unit files,
jobs, init scripts) are by *far* easier to maintain than those of sysvinit.

The main reason for this thread is actually to somehow auto-generate
init scripts from systemd unit files. So I could easily imagining
improving upon the current bridge to support running systemd-enabled
services on sysvinit, kind of like start-stop-daemon but also with some
of the most commonly used features in systemd units, such as detecting
readiness properly (-b in start-stop-daemon has a huge warning in the
man-page because of this) and auto-creating sockets and then passing
them via the socket activation protocol. Together with the debhelper to
autogenerate sysvinit files that was suggested in this thread, I could
easily imagine that already for Jessie package maintainance when it
comes to init scripts could be simplified by quite a bit. Some services
requiring very advanced features would obviously not work, because I
don't really want to reimplement *all* of systemd's unit file options
for this, but I do think that one could probably have something that
targets 90% of unit files and only the other 10% (probably mostly
early-boot-services) will need manually written init scripts.




So two questions:

1. Is there any interest in at least the current version of the
cross-init-bridge? If so, I'll add a proper build system, fix the known
quirks/bugs, call that "0.1" and make a debian package out of it. (I'm
not a DD, so somebody else will have to upload it. ;-))

2. Is there any interest in the "big picture" idea? The improved version
of my bridge would be complimentary to the debhelper proposed here, the
design I'd chose is to NOT read unit files but have everything as
command line arguments, and that the debhelper would generate the
required arguments from the unit file. (That has the advantage that once
generated, it's easier to debug those init scripts.) If that is the
case, I'd volunteer to work on the improved version that can start
daemons when started from sysvinit.

Regards,
Christian


Reply to: