On Mon, Mar 14, 2022 at 09:29:56AM +0800, Paul Wise wrote: > On Sun, 2022-03-13 at 18:02 +0100, Christian Kastner wrote: > > I don't think that's a very constructive line of argument. As a former > > maintainer, it was evident that user crontabs (crontab -e) are still > > very popular, as are some other perhaps niche features, and I've never > > had the impression that anti-systemd has anything to do with it. > > As a systemd user who has a large user crontab I have to agree. > > I'd like to migrate to systemd timers, but there are a few blockers:
Also systemd timers require a session to be running, so as I understand it you have to configure lingering (loginctl enable-linger) for users who want to use per-user timers that aren't tied to having an interactive session (surely the common case). This is frankly obscure - there's no mention of it in systemd.timer(5), and I only found out about it from the Arch wiki. I'm not particularly anti-systemd - there are lots of things about it that I like and use. However, I'm not sure the ergonomics of it weighed up against user crontabs are particularly favourable. Unlike init scripts, for instance, it usually requires noticeably more typing to write a systemd timer than a cron job. The trade-off is that you get better observability and fancier controls over when and how things run. That trade-off usually seems to be worth it for packaged cron jobs, but I have a fair few ad-hoc user cron jobs where I don't feel particularly enthusiastic about it. I'd hate to have to write the release notes entry telling people that they had to use timers rather than user crontabs! systemd-cron provides a generator so that the traditional domain-specific language for crontabs remains available, which seems like a decent approach. I haven't used it, but in general I think the crontab syntax is much stickier than the particular cron implementation. -- Colin Watson (he/him) [cjwat...@debian.org]
