Re: Integration with systemd
On Wed, Oct 30, 2019 at 03:30:17PM -0400, Theodore Y. Ts'o wrote:
> 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.
(I did explicitly say I'd prefer to avoid delving into any one feature,
rather than the overall issue.)
A few values of using a .timer unit:
- Support for spreading the timer activations out so a network full of
systems doesn't all poke a server at the same time.
- Persistent timers, which make anacron unnecessary, and which don't
require waking up and poking anacron periodically.
- Support for timers that only run if another unit is active (without
having to unconditionally wake up and check), and that only count time
another unit is active.
- Support for coalescing timer wakeups to improve power management.
- Support for waking the system from sleep, if desired.
But in any case, the point isn't to advocate a specific feature, the
point is to unblock the possibility of using features *when they provide
an advantage*.
> > 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. :-)
Can we not? Can we just...not? I would love to have a thread about
systemd that manages to avoid gratuitous flames and personal attacks.
> 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.
Only "painful" if we continue to attempt to make the world conform to
the limitations and capabilities of sysvinit.
> > 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).
There's a big difference between "we've mostly accepted that we can't do
otherwise" and "people can safely rely on not getting flamed". The point
of my mail was the latter.
> > 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.
It's not just about upstream. Many of the capabilities of systemd would
be useful in Debian-native components and packaging. And given that, as
you observed, upstream can already use such capabilities, then it
doesn't make sense to stop Debian developers from using those
capabilities, where doing so provides a benefit.
Reply to: