Re: Integration with systemd
On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote:
>
> Today, people can't use systemd persistent timers in place of cron (and
> in place of anacron's "wake up periodically" approach). You have to have
> a cron job as well, and there's no good mechanism to automatically
> prevent a cron job from running when running systemd and a corresponding
> timer exists, so systemd systems would still have to have a pile of cron
> jobs that wake up just to say "oh, I'm on systemd, exit".
Yep, that's what we did for e2fsprogs's e2scrub.timer unit. We
shipped a cron job as well, which exited if systemd was running. It
was kludgy as heck, and to be honest, I'm not sure it actually added
that much value to do it as a systemd timer unit. The person who
contributed the code for upstream did it that way, I suspect because
he was curious about learning about systemd, and fortunately he also
submitted a non-systemd alternative, probably because the enterprise
distro that his $COMPANY supported wasn't using systemd yet.
So not a lot of upside; and interestingly enough, the Debian sysvinit
support for e2scrub was slightly buggy, it took a surprisingly long
time before someone reported it, and we finally got it fixed.
> Systemd user sessions, socket activation, sysusers, dynamic users,
> systemd-homed, temporary directory setup, transient units, anything
> talking to the slice or control group APIs, containerization, firstboot,
> systemd's whole "preset" system-wide configuration and policy mechanism
> for admins to say "what services do I want launched when installed and
> what services do I want to leave stopped until I configure them",
> "stateless system" capabilities, and I'm probably forgetting another
> dozen.
Yep, and this is the "embrace, extend, and extinguish" phenomenom of
systemd which caused so much fear and loathing. Lennart is the
Ballmer of the Linux infrastructure world. :-)
We were kind of lucky because in Debian Stretch, we were stuck on a
pretty old version of systemd that didn't have a lot of these "embrace
and extend" features. I'm kind of surprised this didn't bite us more
in Buster, but it's inevitably going to be an issue moving forward,
and it might not be up to us at Debian; if upstream developers start
using more and more of these Systemd features, if we're not willing to
backport solution for systems that don't have socket activation,
systemd containerization, etc., we're going to be left in a very
painful place.
> Note: I'm not trying to say "we should wholeheartedly adopt every one of
> these technologies"; please don't make this thread about that, or any
> one specific technology. The issue is that we don't even have the option
> of *considering* most of these technologies in the current environment.
> Even if Policy changed tomorrow to have a full "unless you're using
> capabilities that alternate init systems don't have" clause, people
> would still be afraid of using those capabilities or merging patches
> that do so, lest their work become the subject of a giant flamewar. We
> should get to a state where people building something interesting using
> these capabilities and technologies can expect useful feedback, and
> potentially excitement and collaboration, rather than flames.
So mostly, this isn't going to be up to us. It's going to be up to
the upstream. Eventually, for each package where upstream has chosen
to use these technologies, our choice will be (a) to drop the package
from Debian, (b) add backwards compatibility support for systems which
haven't drunk the systemd kool-aid, or (c) mark that the package only
works for systemd.
I think we've mostly accepted that we can't force package maintainers
to do (b), and for many packages, such as for example GNOME, (a) will
be a non-starter, which means we're left with (c).
Of course, someone other than the package maintainer can provide the
backwards compatibility support, and they can either try to pursuade
upstream to accept the patch, or if the change is not too invasive and
not oo onerous to support, they can try to pursuade the Debian
Packager to include it in debian/patches.
> If we're going to have a GR, part of the goal should be to either
> confirm the current state that we're never moving very far past the
> capabilities of sysvinit even when most people don't run it, or that
> we're allowed to use the full capabilities of our default init system
> even when there's no equivalent elsewhere.
I agree, and I think the only thing we can do is to say that upstream
is allowed to use the full capability of systemd --- not that we could
dictate to upstream anyway. And unless we are willing to force
package maintainers to drop packages or to do the work to add the
backwards compatibility, which I think very much goes against the
Debian ethos, especially given the extent of systemd's "embrace and
extend" strategy, I don't think we have a choice but acknowledge
reality and accept that some packages may simply be incompatible with
alternative init systems.
This doesn't make me terribly happy, but there are a lot of things
don't make me happy about our world today. The current occupant in
the US White House, for example. However, not facing reality isn't
really going to help the situation.
- Ted
Reply to: