Re: systemd services that are not equivalent to LSB init scripts
Hello.
Theodore Ts'o - 14.07.19, 22:07:
> So requiring support of non-systemd ecosystems is in general, going to
> require extra testing. In the case of cron/systemd.timers, this
> means testing and/or careful code inspection to make sure the
> following cases work:
>
> * systemd && cron
> * systemd && !cron
> * !systemd && cron
>
> Support of non-systemd ecosystems is not going to be free, and some
> cases, it is not going to be fun, something which many have asserted
> should be something we should be striving for. The challenge is how
> do we develop the consensus to decide whether or not we force
> developers to pay this cost.
I believe forcing someone who does volunteer work by maintaining
packages for Debian is not going to work out. Or even more so: I do not
see how Debian project could force developers. The only effective way to
force anything would be to threaten with loosing membership status or
privileged. But I would not go that route as I see it as destructive
one.
> And if we don't, is it better to just let this rot where we allow
> developers to violate current policy with a wink and a nudge until
> it's clear that we do have consensus? Or do we force them to do the
> work? Or do we somehow go through the pain and effort to try to
> determine what that consensus actually is?
I do not have a solution for the divide behind all of this.
But I do have some hints that may be beneficial or constructive to
someone:
There is a group of Debian developers in the Debian Init Diversity team
working on exactly that: diversity regarding init systems. This is a
group consisting on both Debian and Devuan developers who decided that
working together is going to benefit both Debian and Devuan. Some people
of that group did a *ton* of work to improve sysvinit, insserv,
startpar, runit and I believe also openrc packages. When I look at the
bug tracker I believe sysvinit in Buster is in a better state than it
was since a long, long time. It even has a new upstream maintainer who
actively dug through Debian bug reports with the aim to fix as much
upstream bugs as possible. Also another developer worked on elogind
package. I running Debian Sid with Plasma desktop on Sysvinit since more
than a month already. It needed some minor tweaks as for example
Pulseaudio was not started automatically and Evolution which I use for
work needs some services that are nowadays started by user systemd
service files. I am currently using some quite half baked user services
frontend for runit for starting these I worked on some time ago.
So I believe there is some talent to draw from when it comes to
supporting alternative init systems within Debian packages. Both within
Debian and Devuan communities.
So far the Debian init diversity team runs their publicly accessible
mailing list on infrastructure outside Debian, also to stay out of the
heat of all the discussions regarding systemd and focus on getting
actually work done.
As for the fio package I maintain: I did a sysvinit script myself for it
and I am gladly willing to accept patches to support other init systems.
During that work I was even able to improve upon the upstream systemd
service file considerably as I learned about an option to daemonize fio I
was not aware of.
Testing sysvinit stuff can be done on either Debian or Devuan inside a
VM. Actually for me it is the other way around: To actually test the
systemd service file for the fio service I need to use another system
meanwhile, as my main laptop runs on sysvinit and elogind since more
than a month and I have no intentions to change it back at the moment.
Instead I plan to switch my other laptop as well, which should be as
easy as:
apt install elogind libpam-elogind-compat sysvinit
In addition to that if you have some cron job or sysvinit script which
requires some testing I am happy to help out as I manage to allocate
time for that. I am not sure whether that libpam-elogind-compat package
from experimental is still needed. Also it can easily be switched back
to Systemd as well as well.
That mentioned I believe there is no use in forcing anyone to do
anything within the Debian project except what is necessary to maintain
the boundaries of a code of conduct which helps everyone who uses Debian
or contributes to it welcome.
Again, I do not have a quick or easy solution. And I may be the only
Debian package maintainer who switched his main system to sysvinit, but…
it may still be interesting to read about this different perspective
here.
I did not share my reasons for switching to Sysvinit. Simply because I
am just not interested in triggering yet another discussion for or
against Systemd here.
Thanks,
--
Martin
Reply to: