Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)

[Simon Richter <sjr@debian.org>]

Hi,

On Thu, Aug 15, 2019 at 10:40:22AM +0200, Enrico Zini wrote:

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

Good idea.

> 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.

This will be difficult for services that in the systemd world are
demand-activated to avoid having to specify their dependencies. I am fairly
sure that most people using sysvinit still want to start up services
immediately on boot, which unit files for demand-activated services don't
even describe how to do.

So we might have to invent magic comments still and/or convinve systemd
people that it might be a good idea to have unit files that can support
both immediate and on-demand start.

> 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 doubt people really use more unit file features, at least not for user
space services (where the systemd and sysvinit worlds overlap), so that
shouldn't be much of an issue. I still expect some init scripts to stick
around for cases where unit files are not expressive enough, and I expect
that to get worse when systemd actually gets a versioned API.

> 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.

I'd still be in favour of adding this to start-stop-daemon, because all
that needs is an unit file parser in addition to its command line parser
(which is already complex). Helpers for socket and dbus activation would
also be possible, but I'm not convinced this is actually what people want.

   Simon