| > It's not going to look as clean. Is that what you mean? Nope. I don't give a shit how "clean" something looks, [0] I just care how difficult it is to learn and either retain or remind yourself of the syntax when you need to do something complex with it. In that regard, [1] systemd-crond's scheduler syntax is at least as complicated as that of most crons'. > You don't have to count fields to figure out whether you're dealing with a day vs a month, or an hour vs minute, no matter how the fields are aligned or how long or complex they are. You can scan left and right and look for space and dash and colon to figure out where you are. So, you have to learn a tool-specific format. Just like you do for crontab. I've read both man pages, and I'm 100% unconvinced that systemd-crond's scheduler syntax is actually simpler. I do agree that it can express specific schedules that one cannot in the syntaxes used by most cron implementations. > Very little follows from cron's format. You have to learn which fields are which for your particular implementation: Sure. And I expect that exactly nothing other than systemd-crond uses its weirdo syntax. And -as I mentioned in the comment you're replying to- Nah. It's just there are a very large number of cron implementations. If The Systemd Project were actually a thing that people could make an independent reimplementation of, we'd see at least as much inconsistency in 'systemd-cron' scheduling syntax as people extended it in their reimplementations to meet their needs.
> But no, cron logic is that day and weekday are ORed. It lets you do clever things like run a script on the 1st and 15th of every month, AND on mondays, all in one line. I don't think I've ever seen such a thing in the wild. I'd go so far as to say it's stupid...On this I agree with you. Changing the rules for the Day Of The Week column (but only when it's used in combination with the day of the month column) is catastrophically idiotic. The only time I've ever had need to use the DoW column was to schedule something to run weekly... so I've been blissfully unaware of how incredibly idiotic that behavior is. [0] If anything, I've noticed a strong inverse correlation between how "clean" a syntax is regarded to be and how easy it is to both do complicated things with it, and come back to those complicated pieces of work six+ months later and be able to understand what the hell you did. [1] With the notable exception of cron's DoW column.... read on for further discussion. |
Nobody is all that happy with cron's limitations. That's why there are so many variants, with varying features. When a variant has more than 5 fields, the syntax becomes ambiguous... not to a parser, but to whoever's reading and writing the lines, unless they already know the exact cron variant in use. Google, the one large cloud provider that seems to have stuck with basic cron syntax without quartz-scheduler extras, even invented their own pseudo-natural-language scheduling syntax to fill in for features cron lacks, or for people who don't like cron syntax.
Systemd's is definitely novel, but as I keep repeating, it's ISO8601 + cron. An alternative would be some extension to ISO8601 interval syntax, but that looks clunky and has probably never been used outside of niche applications for data interchange, probably inside xml files; it's used in https://docs.cibseven.org/manual/2.0/reference/bpmn20/events... (syntax at https://en.wikipedia.org/wiki/ISO_8601#Durations ). I think systemd's syntax is better than that.
The direct benefits, even if cron syntax suffices: Calendar timers are integrated with systemd, with all its process-management capabilities[1]. Unifying to systemd timers also avoids duplication of functionality ("is this scheduled process managed by systemd or cron?"). Cron doesn't let you `systemctl list-timers --all`. You'd have to grep through cron logs, possibly (and ironically) using journalctl, or have those logs already in a management dashboard, and that still doesn't let you see the next time the timer would fire. Cron also doesn't let you beta-test cron lines like you can with `systemd-analyze calendar --iterations 10 "Fri *~8..14/1"`
There's even a systemd-cron translator/generator that's in the official debian/ubuntu repos, and in Arch's AUR of course, which avoids the need for system cron but allows you to retain existing crontabs by importing them as systemd timers. They won't be quite as well integrated because it uses defaults for task names and other parameters, but the crontabs get run... without cron.
[1] https://unix.stackexchange.com/a/281203