Love systemd timers

jjgreen

I've been almost convinced by systemd (and have switched to using it), but God the syntax of those service files is so ugly ...

iso1631

> humble systemd

hombre_fatal

NixOS comes with systemd, so I've been using it as a first-class part of managing stuff. It's great, especially coming from macOS' launchd. Which makes it nice to distribute a tool for NixOS so that it can lean into systemd instead of as some bolted-on afterthought. Makes me wonder what you'd do if you were distributing a lifecycle-heavy tool for Linux users in general since systemd isn't ubiquitous. I use a systemd timer to run a monthly scrub for my btrfs pool. Kinda cool how you can do increasingly useful things like skip the next scheduled event if the user initiates a scrub, do or don't accumulate tasks if you have a monthly task but the machine was offline for 6 months -- or fold them into a single task, etc.

ktm5j

Oh I love them quite a lot! I use them to run all of our backup jobs, easy to set up and have never had an issue.

andrewstuart

Even better is systemd socket activation.

gchamonlive

Moved 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-backups

stryan

Timers can work with arbitrary units (not just a similarly-named service unit) so they can be surprisingly flexible. I have a timer on my servers that starts a backup.target that fires off a full "restic backup","restic prune", "restic forget" backup cycle each morning with randomized start times and notifications. The actual restic-* units are Podman Quadlets so the whole setup runs agnosticaly of what's on the server, just as long as it has Podman and Systemd installed. I will admit thought, timers are up there in terms of being the clunkiest systemd unit type to use on a regular basis. I get why they're split up into two files and require different start vs enable syntax's, but man sometimes I just want to create a file that runs a script and be done with it.

lanycrost

systemd is complex on first view, but after using it you didn't want to use anything else. It's handy to manage everything using systemctl

NikhilVerma

I have a Canon printer, I actually can't trust that their print nozzle won't get jammed up after sitting idle for a while. So I had claude setup a systemd script to print a picture of my dog every week, I ensure it has enough CMYK spectrum to stress the printer. Its a nice surprise every monday as I sit on my desk to see a sudden picture pop up from the printer :)

frays

I've been using Linux for over 20 years, systemd for over 10. Yet there's always something new to learn and actually consider as another useful tool.

sammy2255

I'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.

thomashabets2

I haven't used systemd timers enough to disagree, but > Ambiguous $PATH settings make cron script execution difficult to predict. What makes you say that? You can set the PATH right in the crontab. Is that harder to "predict" than it being set in /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/…, or wherever else? > You might feel cool knowing the scheduling grammar by heart I've used Linux since 1994 and I don't know it by heart. But luckily it's pre-printed in the crontab as comments: # For more information see the manual pages of crontab(5) and cron(8) # # m h dom mon dow command You just put numbers aligned with the titles. The rest of the complaints, sure. Next time I need a cronjob, I'll try it out.

cmsj

Is 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.

baggy_trough

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.

kayson

I 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!

sunshine-o

This 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.

mkesper

There'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...

mindcrime

I haven't always been the biggest fan of systemd in some regards, but I will say that I mostly agree with this sentiment. I've almost completely quit using cron, and now favor systemd timers for scheduled jobs - at the "system" level anyway. I might still embed Quartz for scheduling that's scoped to a particular application or something. Why? It's one of those fuzzy and somewhat hard to explain things. The systemd approach just maps more cleanly to my mental model of "how things should work" I guess. And maybe some of it is that I did indeed experience plenty of " Ambiguous $PATH settings make cron script execution difficult to predict" in the past, although it's not just that. I won't sit here and claim that systemd timers are necessarily better than cron in any universal / objective sense. But they've won me over, for what it's worth.

chuckadams

I believe one of the major distro lines (redhat or debian, I forget which) uses systemd-cron, where cron is just a thin wrapper around systemd. You get more power from writing the unit files directly, but if all you ever need is a simple cron job, you have the old interface still available.

pull_my_finger

I'm fully ready to drink the "just let systemd do all the things" kool-aid, but I would love to see some sort of introductory/tutorial info into some of the things it can do other than services - i.e. containers and timers. I know man pages exist, but it would be nice if there was more scannable intro out there.