Re: systemd services that are not equivalent to LSB init scripts
Vincent Bernat <bernat@debian.org> writes:
> ❦ 14 juillet 2019 12:30 -07, Russ Allbery <rra@debian.org>:
>> There seems to be a clear infrastructure gap for the non-systemd world
>> here that's crying out for some inetd-style program that implements the
>> equivalent of systemd socket activation and socket passing using the
>> same protocol, so that upstreams can not care whether the software is
>> started by systemd or by that inetd, and provides an easy-to-configure
>> way for Debian packages to indicate this should be used if systemd
>> isn't in play.
> What's the point? The alternative to not using systemd socket server is
> to run the daemon as usual.
The point is to support on sysvinit services that, upstream, only support
socket activation.
> If an upstream decides to tie a daemon to systemd socket server by
> delegating the socket creation to systemd, why would we need to
> implement anything? Don't we have better things to do? This init
> diversity crusade is eating our time.
I'm not saying you should write this. I'm saying that people who want to
support alternatives to systemd should consider writing this, since it
would make it much easier to continue to support a whole class of services
on both systemd and non-systemd environments.
In other words, I think the best way forward for those who want to support
alternatives to systemd would be for those interested to collaborate on
building tools that implement the functionality of systemd unit files
without being tied to systemd. That way, there could be a suite of tools
that either interprets unit files directly or that could use some
configuration generated automatically from unit files. That way, we've
separatedly the API from the implementation and added multiple
implementations, and hopefully this will significantly increase the
chances that packages will work on non-systemd systems even if the
maintainer doesn't test them on such systems. One such tool would be an
inetd-style service that implements socket activation. Another could be a
jailing wrapper program that implements the namespacing and syscall
filtering features of systemd. And so forth.
For better or worse, the unit file syntax is becoming increasingly common
upstream, and more upstreams assume they can configure their software with
that syntax and get a consistent set of features. Implementing that
configuration syntax and those features seems more likely to me to be
viable in the long run than maintaining multiple configuration sets for
every package.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: