Tyblog | You Don't Love systemd Timers Enough

4

WakeSystem doesn’t work properly for some people: Systemd timer with WakeSystem=true not counting down when system is suspended - Fedora Discussion

It looks like the issue you point out was fixed? Obviously not fun to encounter a bug but “bug-free software” is still a challenging bar to meet.

Also, suspend does not work properly on Linux on many laptops, so I don’t know how useful this feature actually is.

It’s unclear to me why the systemd project is responsible for ensuring that the Linux kernel is reliably capable of achieving suspend?

Timers can’t start a unit every X days or on every Xth week of the year, at least I wasn’t able to find how.

Perhaps this transcript between myself and a freely available LLM could help:

I’m a belligerent Linux user with reading comprehension issues. How can I write a systemd timer expression that accomplishes “start a unit every X days” or “on every Xth week of the year”? Respond concisely, just include the relevant examples.

For “every X days”, use a monotonic timer if you mean “X days after the last activation”:

[Timer]
OnUnitActiveSec=3d
Persistent=true

For “every Xth week of the year”, OnCalendar supports ISO week numbers:

Every 4th ISO week:

[Timer]
OnCalendar=Mon *-W01/4-1 00:00:00

I elided the various references and other helpful examples it offered.

A persistent timer will start the unit even if the missed execution occurred so while back that there are only a few minutes until the next execution. You should be able to define the limit of the amount of time since the last missed execution that still causes the unit to be started late. This feature is useful when you want there to be at least X seconds in between executions of your desired script.

Sounds like a feature that doesn’t exactly meet what the behavior described in Persistent= does, do you have a link to the feature request issue handy?

Having to create two files to create a cronjob makes adhoc usage annoying. Being able to just run a command that specifies the time and the command to be executed on time is more convenient.

  1. “just run a command that specifies the time” it sounds like you may not be aware of this systemd-run flag that does exactly what you describe.
  2. This is personal preference; but I like the distinction between “this unit of configuration defines the schedule” and “this unit of configuration defines the execution”. Moreover, the .timer abstraction can target units other than just services which grants it a degree of flexibility.

Because of these missing features, I think I love timers as much as they deserve.

Although I count a singular missing feature from your list, I would agree that the project is deserving of praise for its responsiveness to bugs and various features that met the use cases you described!