[systemd-devel] Persistent timers delay Type=idle units

[Andrey Borzenkov]

В Wed, 23 Apr 2014 20:30:35 +0200
Lennart Poettering <lennart at poettering.net> пишет:

> On Wed, 23.04.14 13:15, Leonid Isaev (lisaev at umail.iu.edu) wrote:
> 
> > > Hmm, this sounds nasty. I wodner what we can do about it...
> > > 
> > > Maybe we should add a new setting PersistentExtraSec= to timer units or
> > > so which allows delaying these kind of timers by an extra margin. Would
> > > this work for you?
> > 
> > Yes, I think so. Actually, that's what Thomas proposed on
> > arch-general...
> 
> Hmm, thinking about this: the problem is actually not restricted to
> persistent timers, any timer that has OnBootSec=10ms or so is also
> affected by this, should the boot take longer than 10ms...
> 
> Another option might be to change what Type=idle means: instead of
> making it wait until the job queue is empty it might be better to simply
> make it wait until the default job is finished (with other words, until
> graphical.target is reached).

I think it was discussed in the past and it was exact reason Idle was
introduced - because default.target is not accurate representation of
finished startup sequence.

Is it technically possible to track jobs that resulted from
dependency closure of default.target? I.e. all units pulled in
(directly or indirectly) by default target? This would probably be more
accurate approximation of "at the end of startup" and automatically
fix problem discussed here. It would also provide more or less useful
"startup finished" synchronization point.

>                              That way it doesn't matter what services
> are added in by timers... Somehow this appears like the better solution
> to me. This probably also means changing the manager state machine, and
> splitting its "starting" state into two: one state for the time until
> the default target is not yet reached, and a second state for the time
> until the job queue is actually empty.
> 
> I added this to the TODO list now. I'd be happy to take a patch for this
> though!
> 
> Lennart
>