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

[Lennart Poettering]

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.

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).

Does this make sense?

Lennart

-- 
Lennart Poettering, Red Hat