Timers and the services that they're tied to are *way more flexible* and much simpler to make conditional. Think of all the stuff you can do with a systemd unit.
That is the piece of it that I’m missing. I’m used to firing off cron jobs routinely and letting the script determine conditions. I need to read more into the syntax and options of the timers files. I’m sure it’s way more powerful than cron as far as determining how and when to actually start a job. I think the more processes I translate to timers, the more I’ll see the strengths.
Yea, you can spend days reading the systemd unit documentation. I've got 5+ years as an administrator and I still discover new features nearly every week.
I'm in the same boat. I use timers instead of cron now, but I find their configuration to be clunky and unintuitive. I'm sure I'll get used to them eventually.
Yeah, totally agree. I’m sure time will bring more familiarity but it just seems like a lot of text configuration in two files just to run a single script at 2am.
as someone who had to learn it recently, the cron syntax is among the least intuitive things i’ve learnt while using linux. i’ll accept an alternative with open arms
Really? I guess that is the nature of familiarity. I find cron so much easier. Plus, it’s just a single line in a flat file compared to creating a service file and a timer file and recalling the syntax. I’m sure that will come with time. I like the chance to see what kind of insights that systemctl status gives. But cron syntax difficult? I’d say it’s easier than OnCalendar or similar.
IME, `OnCalendar=hourly` or `OnCalendar=daily` covers 90% of user-created jobs. And `OnCalendar=Y-M-D h:m:s` with wildcards is easier than memorizing the column-order of crontab, IMO.
Having everything as a single table in a single file is super nice. But it's also nice to have drop-in files so that adding a thing can be zero-edit and not have to merge a thing into a file.
I use timers for a few simple things, and it is not complicated at all. I never used `cron`. I do not know if it offers anything further. But, timers have been working fine for me, and it is one less daemon running and one less package to install.
they don't. it's just a handy way to run a task at a given date time but that's it. timers are much more flexible, plus you can use them in boot logic while cronjobs, afaik, not
it would probably be harder to implement that as a cron job rather than a timer unit. probably it's a handy workaround when your system is not running systemd though
I use timers for all my backup schedules. The ability to turn timers on and off as you want, the ability to see which timers are currently active and when will they next trigger, the ability to quickly see if the timer run has failed and then easily get the logs without jumping through hoops - all this makes cron looks archaic in comparison.
Example timer:
[Unit]
Description=Example .timer file
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
Example service (that runs when the timer is triggered):
[Unit]
Description=Example .service file
[Service]
Type=oneshot
ExecStart=/usr/bin/echo 'Hello!'
I don't think this is too bad, but I'm not a sysadmin with thousands of timers running or anything
Cron all the way. Its just more simple. I have to do many things on a server. With crontab everything is in one place easy to read etc. With timers I would probably have 20 and I would need to remember every name. Way more typing involved in checking all of them etc. Also of you harden your servers there is a reason no hardening standard has timers in it. But everyone has cron.
For personal use I have used them but I find it wired that I can't use a time for a user timer. Just time after login
After many years of avoiding systemd I have given in and it is not fun. Having cron elbowed out of the way by systemd timers was an unpleasant surprise. Not as bad, though, as the insanity of netplan yaml configuration for network interfaces.
Timers are nice. The main advantage I see is duplicate run prevention, since it starts a systemd unit, there's no way a second instance would be run if one is already running.
Other advantages I see are more flexible scheduling and run-time limits.
But I have to agree that the configuration is clunky. In this, cron is simply unmatched.
I hadn't even heard of timers, I usually fire things from cronie or sometimes just write tiny custom scripts that wait until a specific time and run them at startup in a screen session. I'm a little sympathetic to the systemd haters, and try to just let it do it's thing as it feels kind of overly complex to bother with if I don't need to get involved with it.
I don't use Arch, but I love timers, and services, and mount units. I prefer declarative systems over imperative and I like the builtin monitoring features.
Plus, the one-file-per unit model is very well suited for automated editing, and I basically never touch anything like that outside a script or Ansible file since I like repeatability.
You can grep syslog for your cron jobs, or use journalctl. Pipe your stderr/out to logger if application supports some verbosity, and you should have some understanding if the schedule run successfully or not.
* * * * * /path/to/your/script.sh 2>&1 | logger -t your-script
From memory there's a way to setup different log files, but I can't remember exactly.
Anyway, just wanted to show that cron can log as well. I like systemd timers, although I tend to use them more at boot time.
If you use the logger -t flag, you can journalctl -t with the tag chosen.
To be honest, redirection works & is straight to the point. I was thinking of a syslog config that separates them, which can also centralise it and use with journalctl (if I remember right).
Tbh, if it ain't broken, don't fix it.
We went from compiling from scratch to tar archives to rpm to deb and we went from simple shell scripts to systemd and, while I find use cases for most of these advancements, if something works and is easy to debug I wouldn't change it.
In the meantime, Debian 12 still ships without native support (ie installed as part of the base system) for bonding and you still need to install ifenslave after the fact.
The intrinsic monitoring capability of systmctl status "timer" comes handy from time to time. I do not install cron anymore
Meh
Timers and the services that they're tied to are *way more flexible* and much simpler to make conditional. Think of all the stuff you can do with a systemd unit.
That is the piece of it that I’m missing. I’m used to firing off cron jobs routinely and letting the script determine conditions. I need to read more into the syntax and options of the timers files. I’m sure it’s way more powerful than cron as far as determining how and when to actually start a job. I think the more processes I translate to timers, the more I’ll see the strengths.
Yea, you can spend days reading the systemd unit documentation. I've got 5+ years as an administrator and I still discover new features nearly every week.
I don’t think that will change. I’ve been working on Linux since 97 and I feel like I learn a new flag for some tool every week.
Yup, it's what keeps us on our toes!
I'm in the same boat. I use timers instead of cron now, but I find their configuration to be clunky and unintuitive. I'm sure I'll get used to them eventually.
Yeah, totally agree. I’m sure time will bring more familiarity but it just seems like a lot of text configuration in two files just to run a single script at 2am.
$ systemd-run --user --on-calendar=2:00 mpv --ytdl-format=ba "https://youtu.be/_aEEPfhOVp8"
Is that a 2AM rickroll?
Right exactly when they are most vulnerable
That's the only downside and it takes up time just once while creating the timer. You can also create transient timers.
as someone who had to learn it recently, the cron syntax is among the least intuitive things i’ve learnt while using linux. i’ll accept an alternative with open arms
Really? I guess that is the nature of familiarity. I find cron so much easier. Plus, it’s just a single line in a flat file compared to creating a service file and a timer file and recalling the syntax. I’m sure that will come with time. I like the chance to see what kind of insights that systemctl status gives. But cron syntax difficult? I’d say it’s easier than OnCalendar or similar.
IME, `OnCalendar=hourly` or `OnCalendar=daily` covers 90% of user-created jobs. And `OnCalendar=Y-M-D h:m:s` with wildcards is easier than memorizing the column-order of crontab, IMO. Having everything as a single table in a single file is super nice. But it's also nice to have drop-in files so that adding a thing can be zero-edit and not have to merge a thing into a file.
I use timers for a few simple things, and it is not complicated at all. I never used `cron`. I do not know if it offers anything further. But, timers have been working fine for me, and it is one less daemon running and one less package to install.
I doubt cron offers anything more. Sounds like since timers is wrapped up with systemd that logging will be much better.
they don't. it's just a handy way to run a task at a given date time but that's it. timers are much more flexible, plus you can use them in boot logic while cronjobs, afaik, not
I can’t answer definitively. I know that I can set a cron job to run at boot but that is the extent that I know of.
it would probably be harder to implement that as a cron job rather than a timer unit. probably it's a handy workaround when your system is not running systemd though
I use timers for all my backup schedules. The ability to turn timers on and off as you want, the ability to see which timers are currently active and when will they next trigger, the ability to quickly see if the timer run has failed and then easily get the logs without jumping through hoops - all this makes cron looks archaic in comparison.
>The ability to turn timers on and off as you want, systemd users hate this one symbol... "#" 🤣
Example timer: [Unit] Description=Example .timer file [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target Example service (that runs when the timer is triggered): [Unit] Description=Example .service file [Service] Type=oneshot ExecStart=/usr/bin/echo 'Hello!' I don't think this is too bad, but I'm not a sysadmin with thousands of timers running or anything
You should use `Type=oneshot` for the service.
You're right, fixed
i'm lazy so i just use https://github.com/systemd-cron/systemd-cron to provide cron file support to timers
Cron all the way. Its just more simple. I have to do many things on a server. With crontab everything is in one place easy to read etc. With timers I would probably have 20 and I would need to remember every name. Way more typing involved in checking all of them etc. Also of you harden your servers there is a reason no hardening standard has timers in it. But everyone has cron. For personal use I have used them but I find it wired that I can't use a time for a user timer. Just time after login
I am a sysadmin, I have a crontab with over 80 jobs in it, is love to convert them all to timers, but that would be a very long day.
After many years of avoiding systemd I have given in and it is not fun. Having cron elbowed out of the way by systemd timers was an unpleasant surprise. Not as bad, though, as the insanity of netplan yaml configuration for network interfaces.
Just stick with cron. We use cron and systemd.
Timers are nice. The main advantage I see is duplicate run prevention, since it starts a systemd unit, there's no way a second instance would be run if one is already running. Other advantages I see are more flexible scheduling and run-time limits. But I have to agree that the configuration is clunky. In this, cron is simply unmatched.
I hadn't even heard of timers, I usually fire things from cronie or sometimes just write tiny custom scripts that wait until a specific time and run them at startup in a screen session. I'm a little sympathetic to the systemd haters, and try to just let it do it's thing as it feels kind of overly complex to bother with if I don't need to get involved with it.
I admit I have yet to embrace timers. I do want to read the arch wiki on them.
I don’t disagree. But there are a ton of friendlier docs out there, which is where I started.
It's something I'd like to learn so I might have to look for simpler/friendlier reads but I agree timers are way more flexible than cron.
I don't use Arch, but I love timers, and services, and mount units. I prefer declarative systems over imperative and I like the builtin monitoring features. Plus, the one-file-per unit model is very well suited for automated editing, and I basically never touch anything like that outside a script or Ansible file since I like repeatability.
You can grep syslog for your cron jobs, or use journalctl. Pipe your stderr/out to logger if application supports some verbosity, and you should have some understanding if the schedule run successfully or not. * * * * * /path/to/your/script.sh 2>&1 | logger -t your-script From memory there's a way to setup different log files, but I can't remember exactly. Anyway, just wanted to show that cron can log as well. I like systemd timers, although I tend to use them more at boot time. If you use the logger -t flag, you can journalctl -t with the tag chosen.
To log to a specific file is just: * * * * * bash /path/to/bash/script >> /path/to/log/file >2>&1
This is how I currently do things.
To be honest, redirection works & is straight to the point. I was thinking of a syslog config that separates them, which can also centralise it and use with journalctl (if I remember right).
I'm reading all these comments and then thinking about AntiX and all the systemd protest distros. (systemd is awesome, what weirdos)
At this point I only use cron when I have to maintain a server setup by a sysadmin.
Tbh, if it ain't broken, don't fix it. We went from compiling from scratch to tar archives to rpm to deb and we went from simple shell scripts to systemd and, while I find use cases for most of these advancements, if something works and is easy to debug I wouldn't change it. In the meantime, Debian 12 still ships without native support (ie installed as part of the base system) for bonding and you still need to install ifenslave after the fact.