Love systemd timers

Yeah, quite possibly... that one seems familiar! Your Google-fu is quite strong.

> I found the systemd time spec syntax you referenced to be logical and well thought out.

I found this amusing when in combination with

> The only thing that threw me for a loop and seems like "special magic" was

but -regardless- a careful reader notes that I never said that the Timer scheduling syntax was illogical or poorly thought out. It's at least as complicated as crontab-style time syntax, which was my entire point.

Related: Not that it's ether part of the core scheduler syntax or necessarily as nice as having it in the core syntax, but my crontab(5) suggests that one can use things like date(1) to get more fine-grained control over the time of execution:

  As noted above, skip values only operate within the time period they´re attached to.
  For example, specifying "0/35" for the minute field of a crontab entry won´t cause
  that entry to be executed every 35 minutes; instead, it will be executed twice every
  hour, at 0 and 35 minutes past.
  For more fine-grained control you can do something like this:
  * * * * * if [ $(expr \( $(date +%s) / 60 \) % 58) = 0 ]; then echo this runs every 58 minutes; fi
  0 * * * * if [ $(expr \( $(date +%s) / 3600 \) % 23) = 0 ]; then echo this runs every 23 hours on the hour; fi
  Adjust as needed if your date(1) command does not accept "+%s" as the format string
  specifier to output the current UNIX timestamp.

While I expect that you're not one of those people, I know that folks who are accustomed to working with extremely inflexible tools forget (or never learned) that these sorts of things are possible. I'm very aware that people sometimes cut off their own limbs with power tools, but that's not a good reason to ban their use.

> What are people on non-systemd distros like Guix System, Void, PCLinuxOS, and so on using for this? Is there still something better to use than cron?

Instead of `sleep` you can use `at`. But for scheduling `cron` is still the best.

Package: at

at, batch, atq, atrm - queue, examine, or delete jobs for later execution

> In 2026 there are more modern options available

More modern doesn't mean any better or more powerful.

I for one hate this need for going "more modern" without having clear and factual advantages.

> Regardless of exactly how clean the environment is, my favorite part of systemd is the fact that there is only one regardless of how something was triggered. Whether a unit is triggered via a mount unit, timer unit, udev rule, it's the same units at the end, so it's the same environment.

>

> The same problems that could be caused by a polluted environment in cron can be caused in reverse by a polluted environment elsewhere, when you unwittingly copy a command that depends on some environment being set.

I'm confused about what you need this for? Are you running some utility command that needs the same environment provided by the daemon's service file? If so, any competent init system lets you extend upstream-provided service files. In OpenRC:

  # tail -n 1000 /etc/*/test-service
  ==> /etc/conf.d/test-service  /tmp/maintenance-set.txt
    eend 0
  }
  
  ==> /etc/init.d/test-service  /tmp/start-set.txt
  }
  
  rebuild () {
    ebegin "doing rebuild. IV='$INIT_VAR' OT='$OTHER_THING'"
    eend 0
  }
  # /etc/init.d/test-service start
  test-service              | * Starting test-service daemon ...                                [ ok ]
  # /etc/init.d/test-service maintenance
  test-service              | * doing maintenance. IV='init var' OT='overriden other-thing' ... [ ok ]
  # /etc/init.d/test-service rebuild
  test-service              | * doing rebuild. IV='init var' OT='overriden other-thing' ...     [ ok ]
  # pgrep --list-full socat
  133705 /usr/bin/socat UDP-RECVFROM:6666,fork SYSTEM:/bin/true

The environment when the service is starting is effectively identical to the one when our custom function is being called:

  # diff -u0 /tmp/*-set.txt
  --- /tmp/maintenance-set.txt 2026-06-02 23:53:19.703048431 -0700
  +++ /tmp/start-set.txt 2026-06-02 23:53:15.265094855 -0700
  @@ -9 +9 @@
  -BASH_LINENO=([0]="410" [1]="0")
  +BASH_LINENO=([0]="409" [1]="0")
  @@ -11 +11 @@
  -BASH_SOURCE=([0]="/etc/init.d/../conf.d/test-service" [1]="/usr/libexec/rc/sh/openrc-run.sh")
  +BASH_SOURCE=([0]="/etc/init.d/test-service" [1]="/usr/libexec/rc/sh/openrc-run.sh")
  @@ -30 +30 @@
  -FUNCNAME=([0]="maintenance" [1]="main")
  +FUNCNAME=([0]="start_pre" [1]="main")
  @@ -64 +64 @@
  -PPID=133712
  +PPID=133702
  @@ -69 +69 @@
  -RC_CMD=maintenance
  +RC_CMD=start
  @@ -73 +73 @@
  -RC_OPENRC_PID=133710
  +RC_OPENRC_PID=133700
  @@ -75 +75 @@
  -RC_RUNSCRIPT_PID=133711
  +RC_RUNSCRIPT_PID=133701
  @@ -93 +93 @@
  -_='doing maintenance. IV='\''init var'\'' OT='\''overriden other-thing'\'''
  +_=']'

So, if you need to do maintenance for a service on a schedule in the same environment that is provided for starting that service, you can simply extend the service script and use cron to execute that functionality.

But. Another thing that confuses me is why you think that SystemD [0] provides anything special here? If you were to create a service file in most any other service manager and start it with cron, you'd get exactly the same environment sanitization as you get for all other services. Given your testimony, I expect that prior to SystemD, you'd have refused to create service files for things like one-off jobs that weren't system services... so why are you okay with it now that you're using SystemD?

[0] I spell it "SystemD" not to mock it -as I understand some do- but to distinguish The Systemd Project from systemd(1). It sucks minor ass that the two share the same name, but what can you do?