[changed subject because I can't stand the old one]

On Fri, Aug 09, 2019 at 08:46:18PM +0200, Simon Richter wrote:

> I can totally see the benefit of using systemd unit files as init scripts
> through start-stop-daemon, because we could have a common "open socket,
> chroot, drop privileges" wrapper that way, most of the code is already
> there (start-stop-daemon's command line is a descriptive interface) and it
> would still be simple enough to fully understand in a single day.
> If I went and implemented the "API" by implementing all the features in the
> man pages, I would indeed get the single property I like the least about
> systemd: that its specification is always in flux.
> I am fairly sure it would be possible to define a more powerful API than
> init scripts. Alas, that hasn't happened yet, because nobody is willing to
> create a normative reference.

Alternatively, we can decide on a subset of unit files that would cover
the normal start-stop-daemon features, and like 80% of initscripts, and
would be very unlikely to be changed anytime soon by systemd upstream,
and decide that if that's all you need for your /etc/init.d script, you
can just ship the unit file and delegate the sysvinit case to the
start-stop-daemon equivalent.

Those packages that use more unit file features can still ship an init.d
script, but at least all those packages that just start/stop a service
don't need to bother about maintaining yet another shellscript that
bitrots dangerously over time.

I even have a python implementation of most such unit file features that
I can offer as a starting point, please give me a few days[1] to talk to
one of my customers about putting it into a public git repo.


[1] today's a national holiday in Italy: 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>

Attachment: signature.asc
Description: PGP signature

Reply via email to