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 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. 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  http://lists.debian.org/debian-devel/2013/05/msg01337.html  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.
Description: Binary data