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.<p>Btw this is my repo for the backup automation: <a href="https://github.com/gchamon/borg-automated-backups" rel="nofollow">https://github.com/gchamon/borg-automated-backups</a>
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.<p>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.
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.<p>Which makes it nice to distribute a tool for NixOS so that it can lean into systemd instead of as some bolted-on afterthought.<p>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.<p>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.
+1, NixOS makes working with systemd a breeze. Defining units in Nix beats wrangling INI files.<p><pre><code> 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" ];
};</code></pre>
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.<p>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.<p>So after I restart all my services manually on reboot I agree, systems timers are cool.
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.
Even better is systemd socket activation.
I've been almost convinced by systemd (and have switched to using it), but God the syntax of those service files is <i>so</i> ugly ...
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?
TOML would look a lot more quiet, but I'm not sure if TOML would be a good fit
key-value pairs where the = cannot be surrounded by spaces, so I have to write<p><pre><code> [Service]
Type=oneshot
WorkingDirectory={{ home }}/current/
Environment=RAILS_ENV=production
ExecStart=/bin/sh -lc "bin/db-backup --verbose"
</code></pre>
which fills me with sadness
Whitespace immediately before or after the equals sign is completely ignored by the parser. Its the standard INI format.
What? You absolutely can have spaces; most of mine look more like<p><pre><code> [Service]
Type = oneshot
WorkingDirectory = %h/current/
Environment = RAILS_ENV=production
ExecStart = /bin/sh -lc "bin/db-backup --verbose"</code></pre>
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.<p>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.
Oh yes, because the well documented clean syntax of sys v init shell scripts was so nice.<p>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.
This is why I like NixOS. Defining systemd services in it is very neat.
Could have been worse.<p>Could have been YAML.<p>Could have been XML.
XML would have the advantage of having a grammar so we could validate the config files.<p>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.
The systemd dialect of INI is actually pretty well-defined though.<p><a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.syntax.html" rel="nofollow">https://www.freedesktop.org/software/systemd/man/latest/syst...</a>
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.<p>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.<p>Oh, and remember times when programmers would argue whether argument order in XML files should be significant or not?<p>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.
There are good GUI editors for XML?
To be honest, I think either of those would have been better ...
GNU/Linux --> Linux/systemd
> humble systemd
[dead]