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

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)



Hi,

On Fri, Aug 09, 2019 at 02:54:55PM +0100, Simon McVittie wrote:

> To a large extent, the design of units and service files *is* systemd.

This is a large part of the systemd criticism as well: the refusal to
commit to an API because it would hinder future development, while at the
same time proposing to make this moving target the official API for service
startup.

Debian Policy is rather explicit about the interface of init scripts,
because that is how services integrate into Debian. I was completely fine
when that interface got extended to allow dependency-based boot using
insserv, and I'm also -mostly- fine with replacing it with something else.

What I'm not happy with is that we have effectively incorporated systemd
unit files as an interface into Debian Policy without *explicitly* doing
so, and that this interface remains "defined by upstream".

If that is what we want, then we should update Debian Policy.

> If
> you don't like the design of systemd, and you set out to implement
> something that implements the same "API" by reading the man pages and
> implementing all the features described there, it's hard to see how you
> could get a result that doesn't have at least some of the same properties
> that you don't like about systemd.

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.

   Simon


Reply to: