# Tyblog | You Don't Love systemd Timers Enough

**URL:** https://forum.tjll.net/t/tyblog-you-dont-love-systemd-timers-enough/625
**Category:** uncategorized
**Created:** [May 5, 2026, 3:45pm UTC](https://forum.tjll.net/t/tyblog-you-dont-love-systemd-timers-enough/625 "2026-05-05T15:45:38Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![tyler](https://forum.tjll.net/letter_avatar_proxy/v4/letter/t/35a633/32.png) [@tyler](https://forum.tjll.net/u/tyler)
#### Post date: [May 5, 2026, 3:45pm UTC](https://forum.tjll.net/t/tyblog-you-dont-love-systemd-timers-enough/625/1 "2026-05-05T15:45:38Z")

</div>

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.

* * *
This is a companion discussion topic for the original entry at [https://blog.tjll.net/you-dont-love-systemd-timers-enough](https://blog.tjll.net/you-dont-love-systemd-timers-enough)

---

<div class="post-metadata">

### Author: ![NormalPerson73060174](https://forum.tjll.net/user_avatar/forum.tjll.net/normalperson73060174/32/89_2.png) [@NormalPerson73060174](https://forum.tjll.net/u/NormalPerson73060174)
#### Post date: [July 8, 2026, 1:33pm UTC](https://forum.tjll.net/t/tyblog-you-dont-love-systemd-timers-enough/625/2 "2026-07-08T13:33:24Z")

</div>

WakeSystem doesn’t work properly for some people: [Systemd timer with WakeSystem=true not counting down when system is suspended - Fedora Discussion](https://discussion.fedoraproject.org/t/systemd-timer-with-wakesystem-true-not-counting-down-when-system-is-suspended/90261)

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.

---

<div class="post-metadata">

### Author: ![tyler](https://forum.tjll.net/letter_avatar_proxy/v4/letter/t/35a633/32.png) [@tyler](https://forum.tjll.net/u/tyler)
#### Post date: [July 8, 2026, 1:33pm UTC](https://forum.tjll.net/t/tyblog-you-dont-love-systemd-timers-enough/625/3 "2026-07-08T13:33:24Z")

</div>



---

<div class="post-metadata">

### Author: ![tylerjl](https://forum.tjll.net/user_avatar/forum.tjll.net/tylerjl/32/21_2.png) [@tylerjl](https://forum.tjll.net/u/tylerjl)
#### Post date: [July 22, 2026, 2:37am UTC](https://forum.tjll.net/t/tyblog-you-dont-love-systemd-timers-enough/625/4 "2026-07-22T02:37:26Z")

</div>

> WakeSystem doesn’t work properly for some people: [Systemd timer with WakeSystem=true not counting down when system is suspended - Fedora Discussion](https://discussion.fedoraproject.org/t/systemd-timer-with-wakesystem-true-not-counting-down-when-system-is-suspended/90261)

It looks like the issue you point out [was fixed](https://github.com/systemd/systemd/pull/36990)? 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”:
> > 
> > ```ini
> > [Timer]
> > OnUnitActiveSec=3d
> > Persistent=true
> > 
> > ```
> > 
> > For “every **Xth week of the year** ”, `OnCalendar` supports ISO week numbers:
> > 
> > Every 4th ISO week:
> > 
> > ```ini
> > [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](https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html? __goaway_challenge=meta-refresh&__ goaway_id=90c19887b55d282d1b5b1db23e59e60b&__goaway_referer=https%3A%2F%2Fwww.google.com%2F#--on-active=) 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!

---

<div class="post-metadata">

### Author: ![NormalPerson73060174](https://forum.tjll.net/user_avatar/forum.tjll.net/normalperson73060174/32/89_2.png) [@NormalPerson73060174](https://forum.tjll.net/u/NormalPerson73060174)
#### Post date: [July 29, 2026, 11:35pm UTC](https://forum.tjll.net/t/tyblog-you-dont-love-systemd-timers-enough/625/5 "2026-07-29T23:35:01Z")

</div>

> [@tylerjl](#):
>
> but “bug-free software” is still a challenging bar to meet.

For some people it certainly is.

> [@tylerjl](#):
>
> It’s unclear to me why the systemd project is responsible for ensuring that the Linux kernel is reliably capable of achieving suspend?

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.

> [@tylerjl](#):
>
> For “every **X days** ”, use a monotonic timer if you mean “X days after the last activation”:
> 
> ```auto
> [Timer]
> OnUnitActiveSec=3d
> Persistent=true
> 
> ```

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](https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html).

> [@tylerjl](#):
>
> For “every **Xth week of the year** ”, `OnCalendar` supports ISO week numbers:
> 
> Every 4th ISO week:
> 
> ```auto
> [Timer]
> OnCalendar=Mon *-W01/4-1 00:00:00
> 
> ```

OnCalendar does not support ISO week numbers. The syntax that the llm provided is pure garbage. systemd-analyze calendar will tell you as much.

> [@tylerjl](#):
>
> 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?

I don’t. I just want a feature similar to that in leahneukirchen/snooze achieved with -T option.

> [@tylerjl](#):
>
> “just run a command that specifies the time” it sounds like you may not be aware of [this systemd-run flag](https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html? __goaway_challenge=meta-refresh&__ goaway_id=90c19887b55d282d1b5b1db23e59e60b&__goaway_referer=https%3A%2F%2Fwww.google.com%2F#--on-active=) that does exactly what you describe.

I was not, it’s good to know it exists.
