tdk
January 19, 2026, 4:17pm
21
@rustybird
I removed user and group. Please give me one with two days to confirm that everything is fine.
Please tell me. I use debian over 10 years. All my systemd services and timers I put them in /etc/systemd/system/ without any problem.
Why qubes I have to put to /etc/systemd/user ? I repeat that the problem is that timer not save the settings oncalendar then when I reboot appvm or entire qube OS the service run again and again.
1 Like
tdk
January 21, 2026, 7:13pm
22
@rustybird
Thank you very much, I am grateful for you.
Can you explain me in previous question? Why do I have to put to /etc/systemd/user.
In the future all my systemd service I have to put in the same directory?
1 Like
It’s a workaround for this bug (see there for technical details):
opened 09:49PM - 21 Jan 26 UTC
P: default
### Qubes OS release
R4.3
### Brief summary
A systemd timer unit can use the… option [`Persistent=true`](https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html#Persistent=), which retroactively triggers the associated service unit if it should already have been triggered while the machine was powered off. This is implemented using a timestamp file recording the last triggering.
For *system* unit timers (as opposed to *user* unit timers), the timestamp files are stored in `/var/lib/systemd/timers/` on the "root" storage volume, where changes in an AppVM don't survive a restart. This means that in an AppVM, timers can simultaneously
- **trigger too often:** every AppVM restart wipes the record of a previous triggering, so systemd assumes it was missed; and
- **trigger not often enough:** the record of the last triggering in the TemplateVM can be inherited by the AppVM, preempting it in the latter.
Both system timers shipped by upstream (e.g. `fstrim.timer`) and custom system timers written by the person using Qubes OS are affected.
This could be fixed by redirecting the timestamp directory to the "private" volume via a symlink. (Or a bind mount. However, `qubes-bind-dirs.service` is not guaranteed to run early enough for an arbitrary timer. fstab [should](https://github.com/systemd/systemd/blob/v259/src/core/timer.c#L142) work though.)
### Additional information
For custom timers, a possible workaround is to have the person using Qubes OS create them as user timers instead of system timers, by placing them [e.g. in `/etc/systemd/user/`](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#User%20Unit%20Search%20Path) instead of `/etc/systemd/system/`. User timer timestamps are stored in `~/.local/share/systemd/timers/` on the "private" volume.
https://forum.qubes-os.org/t/how-do-i-set-up-systemd-service-with-systemd-timer/38597
Only timers with Persistent=true, and the services that should be triggered by the timers. Until the bug is fixed.
1 Like
tdk
January 24, 2026, 12:16pm
24
**@rustybird **
There is another bug in my question here.
Timer starts everyday at 7.00.pm , 14.00 and 21.00. If appvm has started the systemd timer not start when the time is 14.00 or 21.00. To fix that I have to shutdown Appvm then I start again the appvm.
Why?
I’m guessing the service is still considered active from being triggered by the 07:00 timer. Try removing RemainAfterExit=yes
tdk
January 25, 2026, 12:14pm
26
Thank you rustybird.
Do you have any other solution excpet this? My script close librewolf browser then backup some files then load librewolf again.
RemainAfterExit=yes command can do this. If I removed this line librewolf not load again.
You might want to use KillMode=none instead of RemainAfterExit=yes
tdk
January 29, 2026, 3:15pm
28
Thank you very much. It works.
I tried to put KillMode=: control-group, and mixed) because is safer from killMode=none
but It didn’t work. Killmode=none is unsafe.
Thank you again.