Re: Q: systemd-timer vs cron
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) [cjwatson@debian.org]
Reply to: