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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Nov 07, 2014 at 03:13:12AM +0100, Lennart Poettering wrote:
> On Fri, 07.11.14 03:02, Zbigniew Jędrzejewski-Szmek (zbyszek at 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