On Sun, 02.11.14 17:59, Zbigniew Jędrzejewski-Szmek (zbys...@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@.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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel