In decades of trying, I do not believe there was one time that I ever got a cron job to work properly in the first attempt. Systemd timers are a godsend.
Love systemd timers
61–70 of 309 posts
Re: Love systemd timers
#62Is there a way yet to force-trigger a timer? There wasn't the last time I used them, which I found to be super annoying for testing them.
It's covered in the article, you can simply start the unit that would be started by the timer.
Oh but it won't appear in the timer-specific logs, I guess...
Re: Love systemd timers
#63Earlier quoted context omitted.
Friend, you have changed my life
Is this one of those cases where at one point you had an error in the file and you figured it was down to spaces? You fixed that issue, it still didn't work but from that point you never thought to question the assumption. I find myself doing this sort of thing all the time..
That was (cough still is) ddclient for me.
Re: Love systemd timers
#64I've converted all my crons to systemd timers+services over the past year but cant help but think it's sort of.. less tangible than cron Like imagine trying to explain systemd timers and services and unit files to a beginner.
> Like imagine trying to explain systemd timers and services and unit files to a beginner.
I think it's... easier? Like "systemd is the place where your system manages all the processes it needs to run. Part of those processes can be run on a schedule, or on a timer, and you define them using this simple text file".
Re: Love systemd timers
#65I love systemd timers! I've slowly moved all of my ansible-deployed cron jobs to timers (now just an ansible copy!). The integration with journalctl, especially in a newer OS like Debian 13 where syslog is gone, is really nice. It's also really nice to be able to start the service manually for debug. Having a cron job that didn't work was an annoying exercise in copy/pasting or writing an extra shell script. Don't even get me started on the black hole of cron job stdout. I can monitor systemd services like I already do and get a notification on failure.
I've noticed more and more open source projects recommending timers as a deployment method and I think that's great!
Re: Love systemd timers
#66This is actually something that I like in systemd.
I am dealing with mostly non systemd system: BSD, Alpine, termux On BSD anacron works well, but I do not why I am always running into problems with the cronie anacron implementation. And it is very hard to debug.
I would really like a simple modern cron/anacron alternative.
Cronicle looked cool but it is node.js, a bit heavy and being replace now by their new product called xyOps anyway.
Re: Love systemd timers
#67Moved from cronie to systemd timers because they are resilient to system startup times. My backup strategy is to create a borg archive entry every day at a fixed time. With cronie the system needs to be running at the scheduled time, but systemd timer tolerates this and runs the service as soons as the system is available. Btw this is my repo for the backup automation: https://github.com/gchamon/borg-automated-backup…
Cronie has a mechanism for this, called "anacron", which is called hourly by cron (on my system, /etc/cron.hourly/0anacron), and performs all the /etc/cron.{daily,weekly,monthly} tasks, no matter if the earliest possible schedule was missed (and with a configurable random delay). You can modify /etc/anacrontab to create custom schedules. To do this at the user level, you can add something like "@hourly anacron -t /pa…
EDITED
This isn't the same as with systemd timer because timer lets you specify when you want to run your service exactly and will fallback to running when the system comes online. With @hourly I lose this control and multiple machines could potentially trigger backups at the same time, hogging the physical hard drives and the network.
Re: Love systemd timers
#68Earlier quoted context omitted.
This is very interesting. I'm not sure what I'd use it for yet, but I imagine it could be useful for triggering ad hoc jobs over the network. Maybe have Home Assistant make a network call to kick off a daily back up when I leave the office at the end of a work day.
I believe its original motivation was just speeding up boot times by starting fewer services, even if you'd eventually want the service running. This was achieved in the past with xinetd, but systemd made the approach more popular for the masses.
inetd began to fall out of favour in the mid-late 90s as services became more heavyweight and startup times became longer (think of the initial crypto setup needed by sshd vs rsh/telnetd)
CPU speeds have increased & and i/o latency has decreased so much since then that startup times are generally imperceptible, so the pendulum has swung back to favouring socket activation.
The anti-systemd "traditionalists" never seem to acknowledge that history, though!
Re: Love systemd timers
#69Re: Love systemd timers
#70There's another big feature: You're not relying on the time zone to which the server was set (like with cron) but can explicitly specify a time zone:
https://www.freedesktop.org/software/systemd/man/latest/syst...