Arch Linux

mettacrawler

Member

Registered: 2020-09-26

Posts: 26

[SOLVED] What causes a disabled systemd timer to run anyway

Example 1, fstrim timer is disabled and it is also "inactive dead" the way I would expect.

$ systemctl status fstrim.timer
* fstrim.timer - Discard unused filesystem blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; disabled; preset: disabled)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: * fstrim.service
       Docs: man:fstrim

Example 2, man-db timer is disabled but for reasons I have not figured out yet it is "active (running)"

$ systemctl status man-db.timer
* man-db.timer - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.timer; disabled; preset: disabled)
     Active: active (running) since Fri 2023-11-24 15:10:09 EST; 16h ago
    Trigger: n/a
   Triggers: * man-db.service
       Docs: man:mandb(8)

Nov 24 15:10:09 example.com systemd[1]: Started Daily man-db regeneration.

Example 3, same as example 2 but man-db.timer is in "waiting" instead of "running"; it will run sometime in the future despite being disabled.

$ systemctl status man-db.timer
● man-db.timer - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.timer; disabled; preset: disabled)
     Active: active (waiting) since Fri 2023-11-24 13:25:08 EST; 18h ago
    Trigger: Sun 2023-11-26 11:07:18 EST; 1 day 2h left
   Triggers: ● man-db.service
       Docs: man:mandb(8)

Both of the two timer unit files in the example have:

[Install]
WantedBy=timers.target

So it's doubtful that can be the reason one disabled timer is started while the other disabled timer is not started.

The fstrim.timer has two conditions which would inhibit it but neither of those condintions are occurring. It is not in a container and it is not in an "initrd".

ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release

The man-db.timer unit file does not have any conditions at all.

The entire contents of the timer unit files in the examples is:

$ cat /usr/lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused filesystem blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true
RandomizedDelaySec=100min

[Install]
WantedBy=timers.target

$ cat /usr/lib/systemd/system/man-db.timer
[Unit]
Description=Daily man-db regeneration
Documentation=man:mandb(8)

[Timer]
OnCalendar=daily
RandomizedDelaySec=12h
Persistent=true

[Install]
WantedBy=timers.target

What causes a disabled systemd timer to run despite it being disabled? If timer unit files trigger static service unit files, is something triggering a disabled timer unit file? I could mask the timer unit file but that is not what I am asking.

Last edited by mettacrawler (2023-11-26 22:44:46)

Lone_Wolf

Forum Moderator

From: Netherlands, Europe

Registered: 2005-10-04

Posts: 11,952

Re: [SOLVED] What causes a disabled systemd timer to run anyway

disabling a timer only stops systemd from starting it upon boot, it can still be started by issuing a systemctl start some-timer.timer command.

The output of

$ systemctl list-timers --all

may be helpful.

---

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

(A works at time B)  && (time C > time B ) ≠  (A works at time C)

mettacrawler

Member

Registered: 2020-09-26

Posts: 26

Re: [SOLVED] What causes a disabled systemd timer to run anyway

Thank you for your thoughtful reply.  I guess I forgot to mention that I already poked around:

$ systemctl list-timers --all
NEXT                             LEFT LAST                         PASSED UNIT                             ACTIVATES                         
Sat 2023-11-25 11:45:25 EST     24min Fri 2023-11-24 08:04:00 EST       - plocate-updatedb.timer           plocate-updatedb.service
Sat 2023-11-25 13:40:26 EST  2h 19min Fri 2023-11-24 13:40:26 EST 21h ago systemd-tmpfiles-clean.timer     systemd-tmpfiles-clean.service
Sun 2023-11-26 00:00:00 EST       12h Sat 2023-11-25 00:00:16 EST 11h ago atop-rotate.timer                atop-rotate.service
Sun 2023-11-26 00:00:00 EST       12h Sat 2023-11-25 00:00:16 EST 11h ago shadow.timer                     shadow.service
Sun 2023-11-26 11:07:18 EST       23h Sat 2023-11-25 01:48:16 EST  9h ago man-db.timer                     man-db.service
Mon 2023-11-27 05:47:17 EST 1 day 18h Mon 2023-11-20 15:07:12 EST       - reflector.timer                  reflector.service
Thu 2023-11-30 12:26:16 EST    5 days Fri 2023-11-17 12:49:11 EST       - archlinux-keyring-wkd-sync.timer archlinux-keyring-wkd-sync.service

7 timers listed.

$ systemctl list-paths  --all
PATH                      CONDITION         UNIT                              ACTIVATES                           
/run/systemd/ask-password DirectoryNotEmpty systemd-ask-password-console.path systemd-ask-password-console.service
/run/systemd/ask-password DirectoryNotEmpty systemd-ask-password-wall.path    systemd-ask-password-wall.service

2 paths listed.

$ systemctl list-dependencies timers.target
timers.target
● ├─archlinux-keyring-wkd-sync.timer
● ├─atop-rotate.timer
● ├─man-db.timer
● ├─plocate-updatedb.timer
● ├─reflector.timer
● ├─shadow.timer
● └─systemd-tmpfiles-clean.timer

mettacrawler

Member

Registered: 2020-09-26

Posts: 26

Re: [SOLVED] What causes a disabled systemd timer to run anyway

Oops, I only responded to part of your suggestions.

disabling a timer only stops systemd from starting it upon boot, it can still be started by issuing a systemctl start some-timer.timer command.

When I boot the computer, the disabled man-db.timer is started.

$ journalctl -b -0 | grep -i man-db
Nov 24 13:25:08 example.com systemd[1]: Started Daily man-db regeneration.
Nov 25 01:48:16 example.com systemd[1]: Starting Daily man-db regeneration...
Nov 25 01:48:17 example.com systemd[1]: man-db.service: Deactivated successfully.
Nov 25 01:48:17 example.com systemd[1]: Finished Daily man-db regeneration.

mettacrawler

Member

Registered: 2020-09-26

Posts: 26

Re: [SOLVED] What causes a disabled systemd timer to run anyway

Downloaded pre-frobnicated Arch Linux QEMU from that service which builds them for Vagrant.
https://geo.mirror.pkgbuild.com/images/ … asic.qcow2
Installed into libvirt-land using virt-manager.
Buff it up until it has what it takes:

$ sudo hostnamectl hostname example.com
$ sudo reboot
$ sudo pacman -Suy
$ sudo reboot
$ sudo pacman -S man-db
$ sudo systemctl status man-db.timer 
○ man-db.timer - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.timer; disabled; preset: disabled)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● man-db.service
       Docs: man:mandb(8)

So right after installation of the man-db package, the man-db.timer is not started.

$ sudo reboot
$ sudo systemctl status man-db.timer 
● man-db.timer - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.timer; disabled; preset: disabled)
     Active: active (waiting) since Sun 2023-11-26 05:58:19 UTC; 20s ago
    Trigger: Mon 2023-11-27 06:55:43 UTC; 24h left
   Triggers: ● man-db.service
       Docs: man:mandb(8)

Nov 26 05:58:19 mask-timer.trickster.gods systemd[1]: Started Daily man-db regeneration.

On the reboot after installing the disabled man-db.timer is started.

It's an OOTB issue.

Raynman

Member

Registered: 2011-10-22

Posts: 1,539

Re: [SOLVED] What causes a disabled systemd timer to run anyway

man-db contains /usr/lib/systemd/system/timers.target.wants/man-db.timer. That's nothing new, but systemctl used to show these as "enabled (static)" or maybe just "static", instead of "disabled". (Bug? Feature?)

Those "statically enabled" units can not be disabled (I suppose you could use pacman's NoExtract), but they can be (overridden and thus) masked.

mettacrawler

Member

Registered: 2020-09-26

Posts: 26

Re: [SOLVED] What causes a disabled systemd timer to run anyway

Just to be clear, in case anyone is reading this, the phrase "man-db contains /usr/lib/systemd/system/timers.target.wants/man-db.timer" means "the man-db package includes the /usr/lib/systemd/system/timers.target.wants/man-db.timer file" as demonstrated using the "-Qo" (query files that the package "owns")

$ pacman -Qo /usr/lib/systemd/system/timers.target.wants/man-db.timer 
/usr/lib/systemd/system/timers.target.wants/man-db.timer is owned by man-db 2.12.0-1

systemctl used to show these as "enabled (static)" or maybe just "static", instead of "disabled". (Bug? Feature?)

I guess I could play "hunt the bug in the issues/PRs on github".

Thanks.