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

[Lennart Poettering]

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!

Lennart

-- 
Lennart Poettering, Red Hat