Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Love systemd timers

blog.tjll.net

Post reply on HN
Print view View original

21–30 of 309 posts

Re: Love systemd timers

#21

Post by drunner »

hombre_fatal wrote: post #9

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…

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.

Re: Love systemd timers

#23

Post by 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

Re: Love systemd timers

#24

Post by yjftsjthsd-h »

jjgreen wrote: post #15
zamadatix wrote: post #11

Earlier quoted context omitted.

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?

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

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"

Re: Love systemd timers

#25

Post by Cyph0n »

hombre_fatal wrote: post #9

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…

+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" ];
  };

Re: Love systemd timers

#26

Post by pwdisswordfishq »

silvestrov wrote: post #5
WesolyKubeczek wrote: post #3

Earlier quoted context omitted.

Could have been worse. Could have been YAML. Could have been XML.

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.

The systemd dialect of INI is actually pretty well-defined though.

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

Re: Love systemd timers

#27

Post by ramon156 »

zamadatix wrote: post #11
jjgreen wrote: post #2

I've been almost convinced by systemd (and have switched to using it), but God the syntax of those service files is so 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

Re: Love systemd timers

#28

Post by Cyph0n »

drunner wrote: post #21
hombre_fatal wrote: post #9

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…

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=defa…

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 :)

Re: Love systemd timers

#29

Post by 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.

Re: Love systemd timers

#30

Post by voxic11 »

jjgreen wrote: post #15
zamadatix wrote: post #11

Earlier quoted context omitted.

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?

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

Whitespace immediately before or after the equals sign is completely ignored by the parser. Its the standard INI format.
Post reply on HN