Re: [EXT] Re: Re: Re: "OnUnitInactiveSec Timer not firing" issue

["Windl, Ulrich" <u.windl@xxxxxx>]

> -----Original Message-----
> From: Michael Chapman <mike@xxxxxxxxxxxxxxxxx>
> Sent: Wednesday, July 31, 2024 9:14 AM
> To: Windl, Ulrich <u.windl@xxxxxx>
> Cc: Andrei Borzenkov <arvidjaar@xxxxxxxxx>; Mantas Mikulėnas
> <grawity@xxxxxxxxx>; systemd-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: [EXT] Re:  Re: Re: "OnUnitInactiveSec Timer not
> firing" issue
> 
> On Wed, 31 Jul 2024, Windl, Ulrich wrote:
> [...]
> > You wrote "... starting the service manually (or "enabling" it, to be
> > started on boot) would be redundant.", but you also wrote "
> > OnUnitInactiveSec begins counting when service gets stopped. How is this
> > timer supposed to start a service that was never active (and hence never
> > stopped) before?" Isn't that a contradiction? So my question " Can you
> > explain where OnUnitInactiveSec would make sense?" IS justified IMHO.
> > And I think there is no reason to be unfriendly unless you want users
> > "go away".
> 
> The service can still be started in other ways, e.g. with `systemctl
> start`, through socket or path activation, or by being pulled in as a
> dependency of another unit.
> 
> Also, you can combine `OnUnitInactiveSec=` with other directives. For
> instance, you might combine it with `OnBootSec=` so that it fires at a
> particular time after boot, and then some period after each service
> deactivation.

[Windl, Ulrich] 
Thanks, that explains it a bit better. Maybe the manual page for systemd.timer should point out the use cases, i.e. separate major modes (calendar, on-boot, ...) from "minor" modes like OnIncactiveSec that don't make much sense when being use alone.

Ulrich