Define a unit and run it individually to troubleshoot vs modifying the crontab for 1 min ahead Logging in journalctl Built in jitter options to spread tasks across a window in a large fleet Ability to use the unit as a dep for other things Instrumented in systemctl list-timers Store config in user home dir (I think ) for tasks owned by a user

These aren’t really better, they are just different ways of doing things the old fashioned way.

(e.g. put all your logic in one script, test it with “env -“, lock exclusively with flock if you need it, or whatever else you have to hand in your language of choice.)

:shrug:, yeah the old fashioned way is possible too (I have to support both), systemd just gives a consistent pattern to make common tasks easy.

Also the ability to easily keep the task from running multiple copies at once.

A nice feature of Systemd timers is the ability to say something like "run once per 24 hour period, but I don't care when". The task runs at a random time during the period, which is nice for tasks that hit network services, since you don't get a zillion clients hitting the server at the same time. (i.e. local midnight or UTC midnight.)

Package repo updates and Let's Encrypt renewals are a couple services I've seen use this. There isn't a great way to do this with cron that I know of, besides running some script that sleeps for a random duration.

That said, I still use cron for things that don't need this feature because it's portable and I'm just more familiar with it.

Because it integrates nicely with the rest of systemd. If you use systemd, there's no real reason to also have a crond running.

I think both have their use cases. For quick and dirty things (like manual logging/system performance), cron works just fine and is quicker to set up. For tasks that require dependencies or have to happen at very specific points in time (like immediately after the network services are started), systemd is more suited to the task.

There are of course quite a few people who dislike systemd for justifiable reasons (but I doubt it receives the disdain that SELinux does), here's a starting point:

https://ihatesystemd.com/

That said, I very much like systemd and I hope it isn't going anywhere. I think it's improved on a lot of things from the SysVinit days and I hope and believe that its shortcomings will be addressed and improved in the future.

My problem with cron for short tasks is that pretty often I forget to add logging and/or locking. And then machine runs out of resources because of all the parallel jobs, and there aren’t even any logs.

I so much more prefer people to respond with reasons than say you should use abc, why, because it’s better

I've also used crontab.guru a million times, precisely 0 for crond itself. Tons of systems use the same syntax.

So the super dismissive "systemd is better" response is kind of missing the point anyways, even with any type of legitimate justification.

except systemd will be replaced by something else soon whereas cron has been around for a while.

What is systemd being replaced by?

systemd vs initd vs upstart. I am pretty sure systemd will be gone soon too as well. Syntax is harder than upstart for example.

I'm sorry, that ship has sailed. systemd is more than just a init system at this point. Anyway, I'm also curious about what is replacing it soon.

There is an "on boot" parameter which may be handy for things that should run both periodically, and at system start. Narrow use case, but it happens.

Some cron implementations do have @reboot (and several others).

Because `systemctl list-timers` is a nicer output than `crontab -l -u <user>`

Restarts, dependencies, various resource limits, etc.

because it is Deprecated™