On Mo, 31.08.20 16:36, Konstantin Ryabitsev ([email protected]) 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 [email protected] -- do I need to > enable (but not start) [email protected] 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 [email protected], and it lists WantedBy=timers.target, then this just means: add a dep from timers.target to my [email protected] instance so that when timers.target is requested your [email protected] 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 [email protected] 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 _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
