[systemd-devel] [PATCH] unit: do not order timers.target before basic.target

[Zbigniew Jędrzejewski-Szmek]

On Fri, Nov 07, 2014 at 02:49:59AM +0100, Lennart Poettering wrote:
> On Sun, 02.11.14 17:59, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> 
> > Since commit 19f8d037833f2 'timer: order OnCalendar units after
> > timer-sync.target if DefaultDependencies=no' timers might get a
> > dependency on time-sync.target, which does not really belong in early
> > boot. If ntp is enabled, time-sync.target might be delayed until a
> > network connection is established.
> 
> Hmm, this is indeed a problem.
> 
> > It turns out that majority of timer units found in the wild do not
> > need to be started in early boot. Out of the timer units available in
> > Fedora 21, only systemd-readahead-done.timer and mdadm-last-resort at .timer
> > should be started early, but they both have DefaultDependencies=no,
> > so are not part of timers.target anyway. All the rest look like they
> > will be fine with being started a bit later (and the majority even
> > much later, since they run daily or weekly).
> 
> I must say I kinda like the fact that pulling in and reaching
> "basic.target" makes sure all those background things that can fire
> have been set up for firing, and everything else can then just assume
> that things are available and ready.
Yes, that's true, but OTOH, there's a downside to complexity. We have to
explain the difference between timers, and timer-calendar... Timers
can have multiple On* stanzas, so adding an OnCalendar= would move
the timer from one group to another, which would mean that adding
a new On* stanza could *delay* a timer. This behaviour would have to
be documented and explained. I find the idea of simply saying
"timers by default are started asynchronously on boot" much nicer.

> The pretty ASCII diagram I did in bootup(7) kinda makes this visible
> too I figure? 
> 
> > Let timers.target be pulled in by basic.target, but without the
> > temporal dependency. This means timer units are started on a "best
> > effort" schedule.
> 
> Maybe we should intrdouce a new target "calendar-timers.target" or so,
> that is used instead of timers.target for timers that have OnCalendar
> set. That target we could then pull in later, whenever it is
> appropriate.
> 
> This would then feel a bit similar to local-fs.target (which is
> early-boot) and remote-fs.target (which is late-boot).
Two differences: mounts are of one type only, so they cleanly fall
into one of those targets, and two, we actually need to treat them
differently for things to work.

Zbyszek