Hacker News Reader

Comment by notepad0x90 | Hacker News Reader

There is one huge advantage of cron that is usually missed with such comparisons. cron is dead-easy to create and maintain. Systemd timers make sense in certain situations, but in 90%+ of my use cases so far, the added complexity really adds up the amount of time I'm administering my systems. I've been in a situation where I needed to troubleshoot why a systemd timer wasn't triggering, and I didn't like that experience at all. To me, it is something I would use if I actually needed it, it isn't a 1-to-1 replacement for cron.

View on HN

I actually disagree with simplicity. cron does weird things with the environment and it can be hard to correctly reproduce that environment when creating a job and debugging. Conversely, systemd timers are very easy to manually trigger and otherwise behave as a normal oneshot service.

My approach to cron is to assume that you have an empty environment. Just set everything you will need.

Yes this is correct. Something most developers don’t know is that you can set env vars directly in your crontab file.

I’m the developer of crontab.guru and Cronitor.

We have a free tool called CronitorCLI that includes a cron-like shell. You can run and test your scripts in an environment that matches how they will be run by cron itself.

Dude! you're my hero! This is why I like HN :)

Thank you for many years of reassuring me when I doubted my cron-expressions.

As somebody who has made cron jobs my career for the last 11 years, who left a good gig as an engineering director to build a bootstrapped business — that means a lot. It keeps me chugging. Thanks so much.

So you find troubleshooting cron jobs easier?

Cron has no diagnostics whatsoever. Most asked question "How do I force run cron job for debugging" and answer "You don't"

You just add script and pray it works. If it doesn't work there is nothing to work with. No logs, no checks. Nothing.

It not 1-to-1 replacement. It is superior replacement. Cron is just unusable.

> You just add script and pray it works.

All the cron issues I've had boiled down to a difference in env vars. So testing the cronjob means reproducing the environment like this SO answer explains.

https://stackoverflow.com/questions/2135478/how-to-simulate-...

I found the implicit column-based configuration layout of cron rather cubersome. I prefer the key-value configuration layout of systemd timers.

There is also one huge disadvantage of cron: it requires root. Users can create and run systemd timers without root/sudo.

And quite frankly, your experience is likely due to your personal knowledge bias. Systemd timers are quite easy to debug, in fact easier than cron in my opinion. systemctl list-timers lists all the timers, when they last ran, when they will run next, and you can use other commands to inspect each timer in detail and all associated logs.

In contrast, I find cron much harder to debug. Starting with the first problem, you must first figure out what cron is running, as different implementations have different behavior!

One can set up cron jobs under non-root.

You cannot edit /etc/crontab without root. I'm not talking about dropping privileges for the job.

Although speaking of which, cron dropping privileges is not as secure as systemd running as the user before parsing the user's timers, from a defense-in-depth perspective.

But non-root users still have their own crontab, which you don't need sudo to edit.

That depends on which cron you're using, not all of them support user crontabs (and the ones that do probably have subtle differences in behavior).

I was unaware of that, so thank you for the education. But for what it's worth, I have never seen a Linux system which didn't have user crontabs. So even if not universal, it is at least very widespread to the point that you can bet on its presence.

It’s true that root can disable user crontabs but the cron that’s shipped with all popular Linux distributions does have built-in support for them.

Give me an example of cron, which doesn't support user crontabs? Let me list three that support user crontabs: (a) cronie is controlled by /etc/cron.{allow, deny}; when the latter files are not present, every user can submit cron jobs to crond. (b) One can set up Anacron within the user's home directory[1]. (c) systemd timer is another kid on the block; any user can create a systemd.timer unit.

[1] https://opensource.com/article/21/2/linux-automation

Reply on news.ycombinator.com