Timer "OnUnitInactiveSec=1day" is not triggered as expected

Question

I wanted to run a service that runs once per day (exact time of day is not important right now). My interpretation of

OnUnitInactiveSec= defines a timer relative to when the unit the timer is activating was last deactivated.

is that there will be a specified pause between the unit being run (and thus inactive again) and the next invocation.

My units are defined like this:

Service:

[Unit]
Description=User Check (%i)
Documentation=man:[email protected] man:user-check(8)
After=multi-user.target
AssertPathExists=/etc/user-check/common.conf
AssertPathExists=/etc/user-check/%i.conf

[Service]
Type=simple
EnvironmentFile=/etc/user-check/common.conf
EnvironmentFile=/etc/user-check/%i.conf
ExecStart=/usr/bin/user-check \
$CHECK_SELECTION --notification-template=${NOTIFICATION_TEMPLATE} \
$OTHER_OPTIONS
RestartPreventExitStatus=1 2

Timer:

[Unit]
Description=User Check (%i) Timer
Documentation=man:[email protected] man:[email protected]
AssertPathExists=/etc/user-check/%i.conf

[Timer]
OnUnitInactiveSec=1day
Unit=user-check@%i.service

[Install]
WantedBy=timers.target

The timer is both, enabled and started (actually I have four instances). Like this:

# systemctl status [email protected]
● [email protected] - User Check (pw-expiration) Timer
   Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor preset: disabled)
   Active: active (elapsed) since Fri 2024-06-28 13:55:28 CEST; 2 days ago
     Docs: man:[email protected]
           man:[email protected]

Jun 28 13:55:28 v04 systemd[1]: Stopped User Check (pw-expiration...
Jun 28 13:55:28 v04 systemd[1]: Stopping User Check (pw-expiratio...
Jun 28 13:55:28 v04 systemd[1]: Started User Check (pw-expiration...

The service unit had been executed once when the timer was started. I was expecting the timer to fire over the weekend, but it did not.

What's wrong? Is there a "timer checklist"?

I also tried an override using OnUnitActiveSec=15min, but 55 minutes passed since the unit had been active.

When trying OnCalendar=hourly the last activation was an hour ago, but still nothing happened.

It seems "systemctl edit" still requires a "reload" of the unit; doing so seemed to enable the calendar timer, but the original timers just don't work (see the n/a).

The output of systemctl list-timers is:

 # systemctl list-timers
NEXT                          LEFT        LAST                          PASSED       UNIT
Mon 2024-07-01 15:00:00 CEST  35min left  n/a                           n/a          user-check@auth-fail.
n/a                           n/a         n/a                           n/a          user-check@grace-logi
n/a                           n/a         n/a                           n/a          user-check@pw-expirat

Answer 1

Actually the question had been asked at stackoverflow, but wasn't welcome there ("not being a programming question"), and the request to migrate it had no success either, so I had time to solve the problem for myself, but still wanted to document it here:

Obviously the timer des not just have to be "enabled", but also "started" (which seemed a bit odd to me (as usually "starting" means "right now")). Still, the timer would not repeat!

As it turned out the service unit itself has to be started (I guess to record some timestamp of the last activation). Then the timer repeated as expected.

One could even argue that this is a bug in systemd (SLES12, systemd-228-157.57.1.x86_64).

The timer list then displays something like this:

NEXT                          LEFT          LAST                          PASSED  UNIT                                  ACTIVATES
Mon 2024-07-08 12:24:22 CEST  2h 18min left Sun 2024-07-07 12:24:22 CEST  21h ago [email protected]            [email protected]
Mon 2024-07-08 12:24:22 CEST  2h 18min left Sun 2024-07-07 12:24:22 CEST  21h ago [email protected]        [email protected]
Mon 2024-07-08 12:26:22 CEST  2h 20min left Sun 2024-07-07 12:26:22 CEST  21h ago [email protected]         [email protected]

However after upgrading the RPM package the timers did not trigger anymore. The "postinstall" script does "reenable" all "is-enabled" instances, and then "restart"s all "is-active" instances.

But the service state is inactive (dead), while the timer state is active (elapsed) since Thu 2024-07-11 13:31:19 CEST; 3 days ago.