[aidenn0]

Here's a snippet for configuring a systemd timer on NixOS. Note that if I were to use the systemd configuration language, it would be spread across two files (the timer and the service itself)[1]. If I don't have "startAt" in the definition, it won't generate the timer file. If I spell it "statrAt" it will give me an error when I generate it (or in my editor if I have that configured). Note it's possible to fallback on using the json-like syntax to generate the ini-like systemd configuration files manually, which is useful to have when needed, but mostly it's about writing fairly simple functions that increase the signal-to-noise of the configuration file by removing boilerplate while at the same time detecting mistakes earlier.

  systemd.services.tarsnapback  = {
    startAt = "*-*-* 05:20:00";
    path = [ pkgs.coreutils ];
    environment = {
      HOME = "/home/XXXX";
    };
    script = ''${pkgs.tarsnap}/bin/tarsnap -c -f "$(uname -n)-$(date +%Y-%m-%d_%H-%M-%S)" "$HOME/ts" '';
    serviceConfig.User = "XXXX";
  };

1: Quick reference if you aren't familiar with systemd timers: https://wiki.archlinux.org/index.php/Systemd/Timers

[yencabulator]

I would 100% choose to write a systemd foo.timer file, and the foo.service file, and reference those.

You're throwing away all the organizational learning and preexisting systemd documentation, and forcing something different on the world. `man systemd.timer` contains no mention of `startAt`; what you have there is something inherently different from systemd.

And what if I want more complex rules, like a combination of intervals and time from boot?

[aidenn0]

> I would 100% choose to write a systemd foo.timer file, and the foo.service file, and reference those.

NixOS gives you this option, and I choose not to. Fortunately nobody is forcing you to use this (or forcing me to not use it).

> You're throwing away all the organizational learning and preexisting systemd documentation, and forcing something different on the world. `man systemd.timer` contains no mention of `startAt`

Not quite throwing it all away, because you can easily observe the output of this before making it live. Yes, systemd.timer contains no mention of startAt because as you correctly observed this is somethign inherently different from systemd. startAt is used by other configuration options to specify items running at specific calendar times, so it's reasonably consistent within nixOS itself.

To read the nix documentation is quite simple (and it shows the currently configured value for you):

  % nixos-option systemd.services.tarsnapback.startAt
    Value:
    [ "*-*-* 05:20:00" ]

    Default:
    [ ]

    Type:
    "string or list of strings"

    Example:
    "Sun 14:00:00"

    Description:
    ''
      Automatically start this unit at the given date/time, which
      must be in the format described in
      <citerefentry><refentrytitle>systemd.time</refentrytitle>
      <manvolnum>7</manvolnum></citerefentry>.  This is equivalent
      to adding a corresponding timer unit with
      <option>OnCalendar</option> set to the value given here.
    ''

> what you have there is something inherently different from systemd.

That's kind of the point. If it was inherently the same as systemd there would be no point to it. Systemd timers are quite boilerplate heavy (compare to e.g. a crontab entry), so when I'm not using nixos, I often end up copying an existing timer and modifying it.

> And what if I want more complex rules, like a combination of intervals and time from boot?

Add a time from boot of 120 seconds with this:

  systemd.timers.tarsnapBack.timerConfig = { OnBootSec = "120"; };

For things that actually use all the bells and whistles of systemd, you'll need to specify all the various details.

[edit]

For a nice hyperlinked searching of options see also:

https://search.nixos.org/options?query=startAt&from=0&size=3...