Cron jobs are nice and simple to create. Until they go wrong then they are a pain in the ass. You need to manage logging yourself. If you forget you root mail will fill up your disk and crash the system. If you forget the mailto setting. If you remember it you justlose all logs and have no clue why something is not working. You need to redirect the output to a logfile yourself. And then risk filling up the disk with logs unless you remember to also set up logrotate. And you then still don’t know when something last ran or if it ran successfully.
So many traps and that is just the logging side of things.
My favourite - and I’ve gotten into arguments with people about this who clearly never just tried it to see what happens - is it never executes things with the shell you think it will.
So many people assume that just because their script says #!/bin/bash at the top that cron is going to run it in bash. The reality is without ALSO setting SHELL=/bin/bash in the crontab file, you’re getting your system’s lowest-common-denominator shell (ash/dash/sh/whatever other gross abomination).
So much time wasted debugging. And I’m generally pretty good at avoiding shell-specific syntax, I’ve seen the abominations of shell scripts some people write.
The one thing I do wish systemd timers offered is cron syntax backwards compatibility, rather than just its ISO8601-style time patterns. An every-5-minutes job that used to be */5 * * * * is now OnCalendar=*-*-* *:0/5:0 and I’m just not sure that syntax is universally an improvement.
So are systemd timers. Seriously. I understood this sort of argument in the years when systemd was relatively new, but nowadays … c’mon, it’s 2 config files in a very simple (the simplest form is just 2 headings with one variable definition each) and common format and (optionally) one command to reload the daemon.
Maybe adding a line to your list of cron jobs is slightly quicker, but you have none of the things systemd offers on top.
OK, tbf I don’t know how much (ana)cron provides. Cleaning up the process tree? Restart conditions? Avoiding service duplicates? Advanced starting & repeating like “5min after boot” or “only after this other service has succeeded”? Can it read abbreviations like ‘daily’ or does it all need to be in that cryptic cron syntax?
Its hard to argue that 2 config files both multiple lines long is simpler then a single line in an existing file. Adding a service to cron is just simpler. But adding all the extra bit you are going to want on top increases the things you need to learn to do and configure correctly.
IMO systemd timers are simpler to get right at a little bit more of an upfront cost to learning how they work. But cron is still simpler to just get something working without caring that much. I still find that ends up biting you in the longer term though though all the missing features you need to add manually on top of that one basic line you added.
Cron jobs are nice and simple to create. Until they go wrong then they are a pain in the ass. You need to manage logging yourself. If you forget you root mail will fill up your disk and crash the system. If you forget the mailto setting. If you remember it you justlose all logs and have no clue why something is not working. You need to redirect the output to a logfile yourself. And then risk filling up the disk with logs unless you remember to also set up logrotate. And you then still don’t know when something last ran or if it ran successfully.
So many traps and that is just the logging side of things.
If your
~mail/rootis more than 0-length, you’re missing valuable information.My favourite - and I’ve gotten into arguments with people about this who clearly never just tried it to see what happens - is it never executes things with the shell you think it will.
So many people assume that just because their script says
#!/bin/bashat the top that cron is going to run it in bash. The reality is without ALSO settingSHELL=/bin/bashin the crontab file, you’re getting your system’s lowest-common-denominator shell (ash/dash/sh/whatever other gross abomination).So much time wasted debugging. And I’m generally pretty good at avoiding shell-specific syntax, I’ve seen the abominations of shell scripts some people write.
The one thing I do wish systemd timers offered is cron syntax backwards compatibility, rather than just its ISO8601-style time patterns. An every-5-minutes job that used to be
*/5 * * * *is nowOnCalendar=*-*-* *:0/5:0and I’m just not sure that syntax is universally an improvement.Other than a re-arrangement of the fields, what is the big difference? Harder for awk to work with?
yes and yes and yes, except:
So are systemd timers. Seriously. I understood this sort of argument in the years when systemd was relatively new, but nowadays … c’mon, it’s 2 config files in a very simple (the simplest form is just 2 headings with one variable definition each) and common format and (optionally) one command to reload the daemon.
Maybe adding a line to your list of cron jobs is slightly quicker, but you have none of the things systemd offers on top.
OK, tbf I don’t know how much (ana)cron provides. Cleaning up the process tree? Restart conditions? Avoiding service duplicates? Advanced starting & repeating like “5min after boot” or “only after this other service has succeeded”? Can it read abbreviations like ‘daily’ or does it all need to be in that cryptic cron syntax?
The ageism creeps out of this one.
Its hard to argue that 2 config files both multiple lines long is simpler then a single line in an existing file. Adding a service to cron is just simpler. But adding all the extra bit you are going to want on top increases the things you need to learn to do and configure correctly.
IMO systemd timers are simpler to get right at a little bit more of an upfront cost to learning how they work. But cron is still simpler to just get something working without caring that much. I still find that ends up biting you in the longer term though though all the missing features you need to add manually on top of that one basic line you added.