You Don't Love Systemd Timers Enough
92 points by yacin 5 hours ago | 47 comments

NikhilVerma 30 minutes ago
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 :)
reply
tdeck 28 minutes ago
I wish printers could have a mode like this to print random images from an album, or a calendar, rather than wastefully draining ink into a sponge every few days.

If nothing else, maybe it could be some kid's high school science fair project idea.

reply
sunrunner 8 minutes ago
How about printing a QR code for a randomly generated private key for Satoshi Nakamoto's Bitcoin wallet, then every few days you get a tiny moment of excitement, hope, and then disappointment. It's still wasteful, but it could pay off big time?
reply
NSUserDefaults 3 minutes ago
Or if you have a printer/scanner combo, you can turn it into a pen pal!
reply
magicalhippo 11 minutes ago
Dad had an Deskjet 720 or something like that.

It sat unused and powered off for a couple of years after he passed, until I needed a color print.

Didn't do anything but hook it up to power and print. Took about 1/5 of a page until all colors were back in action, after that it printed about 20 pages flawlessly.

reply
ThePowerOfFuet 5 minutes ago
Laser printers are your friend. The savings on consumables alone will make it pay for itself.
reply
RicoElectrico 6 minutes ago
I was about to recommend a cheap OKI LED color printer; alas they withdrew from consumer market :/ The colors are super nice and uniform, even if the maximum resolution is only 600 dpi - and the toner won't dry out, which was my brother's crucial purchase criterion; we had HP inkjet clogged more than once.
reply
gchamonlive 2 hours ago
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 tolates 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

reply
mid-kid 28 minutes ago
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 /path/to/anacrontab -S /path/to/spooldir" to the user's crontab, though I've never tried this.

Many cron implementations have a similar mechanism.

reply
frays 26 minutes ago
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.

reply
sammy2255 9 minutes ago
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.

reply
hombre_fatal 2 hours ago
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.

reply
Cyph0n 2 hours ago
+1, NixOS makes working with systemd a breeze. Defining units in Nix beats wrangling INI files.

  systemd.services.sync-recyclarr = {
    serviceConfig.Type = "oneshot";
    path = [ pkgs.podman ];
    script = ''
      podman exec -it recyclarr recyclarr sync radarr
      podman exec -it recyclarr recyclarr sync sonarr
    '';
  };
  systemd.timers.sync-recyclarr = {
    timerConfig = {
      OnCalendar = "daily";
      Persistent = true;
      Unit = "sync-recyclarr.service";
    };
    partOf = [ "sync-recyclarr.service" ];
    requires = [ "podman-recyclarr.service" ];
    wantedBy = [ "timers.target" ];
  };
reply
drunner 2 hours ago
Have you been defining them directly in your flake.nix file? I too am on nixos but I keep all my configurations in their native format and symlink them with nix, that way I can take and reuse that config on a non nixos system easily.

The problem I have found is that nixos doesn't seem to pickup and run systemd timers and services placed into the ~/.config/systems/user folder and additionally things like WantedBy=default.target have no effect.

So after I restart all my services manually on reboot I agree, systems timers are cool.

reply
Cyph0n 60 minutes ago
I define all units in Nix because:

a) It is way nicer and you get decent validation at build time

b) A LLM can port units over if the need arises; it’s a very light abstraction around systemd syntax

c) I personally don’t see how I would ever move to another distro :)

reply
stryan 58 minutes ago
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.

reply
esperent 50 minutes ago
Why do you randomize your backup times?
reply
stryan 25 minutes ago
Should have been more clear: I use RandomizedOffsetSec= to add a random offset to a set start time (usually 4am), to prevent overloading the backup server, not truly random start times.
reply
lanycrost 35 minutes ago
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
reply
alyandon 32 minutes ago
That and systemd having actually useful man pages.
reply
ktm5j 2 hours ago
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.
reply
jjgreen 5 hours ago
I've been almost convinced by systemd (and have switched to using it), but God the syntax of those service files is so ugly ...
reply
zamadatix 2 hours ago
Never thought I'd see hackers saying INI format looked ugly of all things. It's basic, sure, but that's a good thing for something meant to be easily editable by hand from any editor. Otherwise, it's just key value pairs in named sections, how ugly can it be about that?
reply
jjgreen 2 hours ago
key-value pairs where the = cannot be surrounded by spaces, so I have to write

  [Service]
  Type=oneshot
  WorkingDirectory={{ home }}/current/
  Environment=RAILS_ENV=production
  ExecStart=/bin/sh -lc "bin/db-backup --verbose"
which fills me with sadness
reply
voxic11 57 minutes ago
Whitespace immediately before or after the equals sign is completely ignored by the parser. Its the standard INI format.
reply
yjftsjthsd-h 2 hours ago
What? You absolutely can have spaces; most of mine look more like

  [Service]
  Type             = oneshot
  WorkingDirectory = %h/current/
  Environment      = RAILS_ENV=production
  ExecStart        = /bin/sh -lc "bin/db-backup --verbose"
reply
jjgreen 54 minutes ago
Friend, you have changed my life
reply
ramon156 2 hours ago
TOML would look a lot more quiet, but I'm not sure if TOML would be a good fit
reply
kevinmgranger 42 minutes ago
unit files barely have any nesting, so the INI-like format is already 90% of the way towards TOML, no?
reply
mrweasel 2 hours ago
There's definitely some weirdness to certain parts of systemd service files, but was a huge improvement over Upstart and the old SysV-style init scripts.

Over all I think Systemd get way to much criticism. You don't have to use all the parts, but if you care to go through the documentation you'll find interesting features such as journald log-shipping and systemd-machined which can manage containers and VMs.

reply
linsomniac 9 minutes ago
Hard disagree. Compared to an init script, with all its boilerplate, I'd take a systemd unit file.
reply
SEJeff 2 hours ago
Oh yes, because the well documented clean syntax of sys v init shell scripts was so nice.

If I never recall hacking in ulimit calls in the top of buggy shell scripts for crappy old services that done respect pam_limits it won’t be soon enough.

reply
whateveracct 2 hours ago
This is why I like NixOS. Defining systemd services in it is very neat.
reply
WesolyKubeczek 2 hours ago
Could have been worse.

Could have been YAML.

Could have been XML.

reply
silvestrov 2 hours ago
XML would have the advantage of having a grammar so we could validate the config files.

It would also make it much simpler to make good GUI editors for the files instead of the Notepad approach most unix config files take.

reply
pwdisswordfishq 2 hours ago
The systemd dialect of INI is actually pretty well-defined though.

https://www.freedesktop.org/software/systemd/man/latest/syst...

reply
WesolyKubeczek 2 hours ago
Since systemd is successfully parsing its INI files, and barks at you when you put weird shit into them, a grammar for them does exist as well.

XML is that wonderful format that gave us vulnerabilities like death by million laughs, up to a certain moment, you could MitM DTDs, and a whole slew of everything-XML stuff back when XML was like AI is today, none of which I miss today.

Oh, and remember times when programmers would argue whether argument order in XML files should be significant or not?

But XML books with their idealized XML future description did give me the same warm fuzzies as some intricate clockwork mechanism to a Victorian geek.

reply
Juliate 2 hours ago
There are good GUI editors for XML?
reply
wpm 26 minutes ago
Could have been better.

Could have been XML Property Lists.

ducks

reply
jjgreen 2 hours ago
To be honest, I think either of those would have been better ...
reply
WesolyKubeczek 2 hours ago
/me cowers in fear
reply
andrewstuart 2 hours ago
Even better is systemd socket activation.
reply
wmanley 30 minutes ago
I design all my services expecting to receive sockets this way. It makes sandboxing easy as the service itself doesn't need network access to have a listening socket.

It's a shame docker never supported it. I feel like if they had got on board all those years ago there would be broad support across the software ecosystem for it and we wouldn't need half of these complicated iptables rules and proxies and service mesh. It would be a step towards a capability based system.

reply
interf4ce 51 minutes ago
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.
reply
kevinmgranger 43 minutes ago
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.
reply
iso1631 2 hours ago
> humble systemd
reply
pwdisswordfishq 55 minutes ago
That the same cannot be said of its maintainer is another matter.
reply
iluvcommunism 2 hours ago
[dead]
reply