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