Arguably the most important bit of information about timers is how to express a schedule, whether a repeating period of time (which the manual usually refers to as a time span) versus a calendar event (or a timestamp).
Fortunately, I think the man page for this under systemd.time(7) is actually very good with plenty of examples.
You should use it as the first resource when writing timers; it's good (or better) than, uh, casual blog posts by casual writers.
Also, suspend does not work properly on Linux on many laptops, so I don’t know how useful this feature actually is.
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.
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.
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.
Because of these missing features, I think I love timers as much as they deserve.
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.
“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.
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!
I am not saying that it is responsible. My point is that the feature is useless for a significant portion of people that would like to benefit from it. It’s also not fair to say that Linux kernel is responsible for suspend, since it already implements ACPI and it’s the hardware manufacturers’ fault for not implementing ACPI properly in their hardware.
I should have specified that I meant “every X days using an OnCalendar”. Monotonic timers will stop when the pc is off, so for laptops, that are almost always turned off for the night, it is not useful. But, I guess, it’s technically true. You can run a command every X days. I was wrong. Also, what’s the point of setting Persistent to true? Persistent only works with OnCalendar, according to https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html.
OnCalendar does not support ISO week numbers. The syntax that the llm provided is pure garbage. systemd-analyze calendar will tell you as much.
I don’t. I just want a feature similar to that in leahneukirchen/snooze achieved with -T option.