Re: [systemd-devel] [PATCH] unit: do not order timers.target before basic.target
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
Re: [systemd-devel] [PATCH] unit: do not order timers.target before basic.target
On Fri, Nov 07, 2014 at 02:49:59AM +0100, Lennart Poettering wrote: 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. 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] unit: do not order timers.target before basic.target
On Fri, 07.11.14 03:02, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: 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. Well, sure, we'd have to document this, but it's really just one sentence. I think in real-life we'll probably not have too many timers that mix monotonic and calendar triggers... I mean, you do have a point, they are asynchronous anyway, there are no latency guarantees, and it is hence of little value to know that they are established before basic.target... Maybe I can live with moving timers.target to a later point, but somebody needs to update the bootup(7) graphic now! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] unit: do not order timers.target before basic.target
On Fri, Nov 07, 2014 at 03:13:12AM +0100, Lennart Poettering wrote: On Fri, 07.11.14 03:02, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: 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. Well, sure, we'd have to document this, but it's really just one sentence. I think in real-life we'll probably not have too many timers that mix monotonic and calendar triggers... I mean, you do have a point, they are asynchronous anyway, there are no latency guarantees, and it is hence of little value to know that they are established before basic.target... Maybe I can live with moving timers.target to a later point, but somebody needs to update the bootup(7) graphic now! Deal! I'll push an update. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
