[systemd-devel] User/Group overrides in a templated service triggered via timer

[Lennart Poettering]

On Mo, 31.08.20 16:36, Konstantin Ryabitsev (konstantin at linuxfoundation.org) wrote:

> On Mon, Aug 31, 2020 at 04:20:13PM -0400, Kevin P. Fleming wrote:
> > Did you also create an instance of the timer with the same instance
> > suffix? I've got a configuration working like that and it works fine.
> > If you don't want to do that, you can explicitly configure the name of
> > the service to be triggered (in the timer unit) instead of relying on
> > the timer/service names matching.
>
> Ah, hmm... So, I enable and start grok-fsck at foo.timer -- do I need to
> enable (but not start) grok-fsck at foo.service as well?

Enabling just means adding deps from some hookpoint (for example
timers.target or multi-user-target) onto your unit. Hence, if you
enable grok-fsck at .timer, and it lists WantedBy=timers.target, then
this just means: add a dep from timers.target to my grok-fsck at .timer
instance so that when timers.target is requested your grok-fsck at .timer
instance is requested too.

A unit that has no WantedBy= (or anything else in its [Install])
section doesn't need to be enabled — in fact enabling it is a NOP,
since enabling just means applying what is written in [Install]. Your
grok-fsck at .service has no [Install] hence no point in enabling it.

timer units activate their associated service units automatically,
that's what they are about. Thus when you enable+start the timer unit then
that's enough to make sure that the timer runs and will be started
again on next boot, and because it runs it means the associated
service is run when the timer hits.

In some cases it might make sense to add an [Install] section to
service that is normally activated via a timer unit: for example when
you want the thing to run under multiple conditions, e.g. both at boot
and regularly at some specific time.

Lennart

--
Lennart Poettering, Berlin