Re: Debian Buster release to partially drop non-systemd support
- Date: Tue, 16 Oct 2018 14:48:10 +0200
- From: Philipp Kern <pkern@xxxxxxxxxx>
- Subject: Re: Debian Buster release to partially drop non-systemd support
On 2018-10-16 14:36, Ian Jackson wrote:
Philipp Kern writes ("Re: Debian Buster release to partially drop
Could someone reiterate about what the current state of init diversity
is supposed to be? Is it assumed to be best effort of every maintainer
being required to ship an init script next to the systemd unit that is
actually used by default?
I think describint that as `effort' is rather much.
I don't understand. If I submit a merge request to the maintainer, it's
on me to test what I submit actually works. So if I add stuff for a
completely different init system I have to test it. The question is: Is
the package buggy if it does not contain an init script but a systemd
unit and it seems to be the case. Note that there are a *lot* of useful
options in a systemd unit that would need emulation to make properly
work with sysvinit.
Can we rely on sysvinit users to report the
bugs with the scripts or how intensively do they need to be tested?
You should rely on users to report bugs.
Okay. In this case I contributed to the package of someone else and
don't want to make it buggy.
Similarly, are maintainers allowed to ship timer units in lieu of
cronjobs? As an example I invested some time in
prometheus-node-exporter to run textfile collectors of monitoring
data (SMART, apt) in the background. Would I have been required by
policy to make sure that all of this also works on a system with
Obviously it would be better to make ti work with cron. Ideally it
would go into cron.daily which I assume works with systemd too.
It'd need to run much more often (every 15 minutes). So cron.daily
wouldn't fit. For the sake of the argument it'd need to be a shell
script that checks multiple conditions (see ). And we currently don't
have timer/cron deduplication, unfortunately. That means it'd also need
to disable itself on systemd systems (but of course cron would still
invoke the script periodically). Similarly - as a more general remark -
having it as a cronjob doesn't let you monitor it in quite the same way.
But if you do just the systemd thing, I think if someone sends you a
patch to make it work with cron I think you should accept and carry
In this case that might be feasible because if it breaks that user is
hopefully going to monitor it anyway, because it's a monitoring thing.
But there is a cost to carrying such things (such as cron confusingly
invoking something whose output isn't used at all because it's going to
be short circuited at startup).