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

[Lennart Poettering]

On Tue, 22.04.14 12:13, Leonid Isaev (lisaev at umail.iu.edu) wrote:

> > Am 22.04.2014 07:07, schrieb Lennart Poettering:
> > > Humm? What precisely do you mean by "delays bootup"? Just scheduling a
> > > timer unit should have about zero effect on boot times... If it does
> > > this would be a bug.
> 
> This is right for the "usual", e.g. OnBootSec= timers.
> 
> Just to give a little background, archlinux has recently replaced daily cron
> jobs (like indexing of man and locate databases) with OnCalendar= timers:
>
>https://mailman.archlinux.org/pipermail/arch-dev-public/2014-March/026044.html
>.

Awesome! This sounds great!

> > From the description that I linked in the first post, it seems that the
> > unit it started as soon as the timer is started. I don't know if "delay
> > bootup" is the right expression, but the Type=idle units, like getty,
> > don't start until the timer's unit finished starting up.
> 
> Right. I see no delay between scheduling an OnCalendar= timer and starting the
> corresponding service. This wouldn't be a problem in general, but if
> the /var/lib/systemd/stamp-... file is old enough, the timer and service are
> launched at boot. However, the latter usually takes some time to start.
> 
> Ideally, one would like to specify the above delay in the .timer file,
> because services started by the OnCalendar timers are sometimes maintainance
> jobs and not always needed for booting the system.

Ah, OK, I think I got it now:

You have services that are to be started by timers that take a long time
to complete. THe timers have been configured to be persistent. If the
system comes up and the timestamp files suggest that the timers need to
be triggered immediately this is done, adding the service execution time
to the bootup time. This is normally not a problem except when there's
some other bootup service that uses Type=idle which will then be
affected by these long running services...

Did I get this right?

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?

> > > What does "systemctl list-jobs" print when this happens? (i.e. when the
> > > bootup is supposedly delayed?)
> 
> I'll have to test this, but I'll speculate that list-jobs will show nothing
> by the time I login, because it takes about 30 sec for me to enter login
> credentials... 

Use "systemctl enable debug-shell"...

Lennart

-- 
Lennart Poettering, Red Hat