[kjkjadksj]

It is a bit crazy to me how everyone says “dont use cron systemd is in now” but cron just does what it says on the tin with no problems. I have lines that work fine ran in script or on my crontab but when wrapped in a launchd command no longer work (log says things work until the db is to be updated which tells me launchd ran processes lack sufficient permissions perhaps to update my db but its not clear why this is the case or how I can elevate launchd sufficiently.

[MrDrMcCoy]

> cron just does what it says on the tin with no problems.

I can name a rather large problem with cron that systemd timers solve handily: long-running job duplication. When jobs take longer to run than the space between their triggering times, duplicates start piling up. I've had to rescue numerous systems from such states, which are difficult to detect until things have gotten quite bad. Sure, you can write a bunch of boilerplate to handle this yourself with cron, but with systemd timers it's all handled for you along with other niceties like capturing all output in journald and ensuring that the next run starts at soon as possible.

[viraptor]

Launchd is not used in systemd - why would anything be wrapped in it? The config is simple - User for the user and Group for the group. You can print it the result of "id" if you're not sure what the result is.

[kjkjadksj]

Sorry I conflate the two since they share a lot of similarity. Launchd is what I use as its a macos system.

[simoncion]

> ...cron just does what it says on the tin with no problems.

Yeah, tell me about it.

We had a production-down support ticket filed for one of the things that I work on at $DAYJOB. The customer's VM's disk was full. Why? Because the 'timer unit' that was supposed to run logrotate every day had never been run and was never scheduled to run. (The VM had been up for a month at this point.) No other customers had ever reported this issue, and we'd not changed anything about that timer unit or what it is supposed to run in ages.

No amount of gyration or agitation with 'systemctl' and friends OR rebooting of the VM kicked the cron replacement into proper functioning. 'logrotate' was simply never being scheduled to run. This fucker was WEDGED, and the tools weren't helping us understand why.

We read through all the docs on all the various kinds of units and don't see what we're doing wrong. We do a BUNCH of digging, and find an -IIRC- open Github issue from years back where someone was running into this problem. More or less the last word on the issue was Poettering saying something like "Well... actually, now that we've said that that particular cascade of options isn't actually supposed to work, now I'm not so sure that they're NOT supposed to work.". And that was -apparently- that.

IMO, when your cron replacement can be easily configured in such a way as to never even try to run the thing that you scheduled it to run, you really need to go back and rethink how you've built your cron replacement.

[teddyh]

Considering how many things of questionable veracity are said about systemd in general, and Lennart in particular, I would like a link to that issue before I take your characterization at face value.

[glandium]

At least systemctl status tells you when next the timer will trigger. Cron doesn't.

[isodude]

Actually it does, have a look at cronnext

[glandium]

First time I hear about it. And it's not surprising, because it's not in cron. It's in cronie, and was "only" added in 2016.

[isodude]

I only found out last week!

Was not aware that vixie cron was first released 1987(https://github.com/vixie/cron/blob/master/Documentation/Chan... 1.md), and still has fresh commits.