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

Re: Survey answers part 3: systemd is not portable and what this means for our ports



On Mon, Jul 15, 2013 at 11:27:22AM +0200, Ondřej Surý wrote:
> Just a quick idea:
> 
> Can we (the mysterious somebody) write a drop-in simple dummy init.d script
> which would take a(ny) systemd service file and run the daemon on
> non-Linux-kernel systems?

I proposed[1] this earlier. The environment for such a wrapper was paved
by upstart already. There is very little to change on the side of
sysvinit to integrate such a wrapper. I have not yet found enough time
to implement this. If someone would be interested to join this effort,
that would be great. The most important requirement here would be time,
then knowledge of C[2]. For completeness sake I am attaching my very
rough draft. Please contact me if you are interested.

> That would reduce complexity for most packages. The maintainers could stay
> with handwritten shell scripts if the init.d script is more complex, but I
> suspect that it would be ok for most packages to just have a simple
> compatibility layer on top of systemd service files.

>From memory I recall that roughly half of the .service files I examined
a few months ago from Debian packages could be quite easily run using
such a wrapper. The main issue here is the need for a new service to be
started very early and binding all the sockets, since we lack dependency
information elided by socket activation.

Again I would like to stress that a more uniform way of interfacing with
services is urgently needed. Currently upstart and systemd have vastly
differing interfaces from the point of view of a service. This is not
limited to the configuration syntax, but extends to the socket
activation API and other aspects. Having either of them adopt an
interface aspect of the other is a net win for everyone, but this has
proven difficult so far.

Helmut

[1] http://lists.debian.org/debian-devel/2013/05/msg01337.html
[2] Even though implementing this in a scripting language such as Perl
    or Python is easier, I do not believe that such a system component
    should depend on an interpreter.

Attachment: s3c.tar.gz
Description: Binary data


Reply to: