Bug#844453: apt-daily.service delays startup by more than five minutes
Control: severity -1 wishlist
On Wed, Mar 29, 2017 at 09:10:19AM -0400, Zack Weinberg wrote:
> On Mon, Mar 27, 2017 at 6:14 PM, Julian Andres Klode <jak@debian.org> wrote:
> > On Mon, Mar 27, 2017 at 12:15:38PM -0400, Zack Weinberg wrote:
> >>
> >> Well, it _is_ run at boot, and in fact _blocks_ boot, so I don't see
> >> specifying that it should run within an hour of boot and not block
> >> anything as a step in the _wrong_ direction...
> >
> > Why should it block boot? It has no dependencies, nor reverse
> > dependencies. systemd is dependency based. It might not consider
> > the boot complete, but it certainly does not affect any other
> > service.
>
> I don't actually know that it blocks in the sense of systemd waiting
> for it to be done before declaring multiuser.target (or something) to
> be available. What I know is that the time from power-on to being
> able to interact with the (gdm) login screen, as measured by an
> external stopwatch, is consistently two to five seconds shorter when
> apt-daily.service is not run during boot. It _could_ be entirely due
> to disk contention -- but I would still consider that sufficient
> reason to not run this during boot.
two two five seconds of how many? My HDD system boots in 30 second
to a minute (inside linux, probably another 10 to 20 or so in BIOS)
, two to five seconds is hardly noticeable on that. If your system
took 30 seconds to boot and now 45 seconds, that would be worth
talking about, but 2 to 5 seconds?
Just for reference: My slow SSD on my laptop boots like this:
$ systemd-analyze
Startup finished in 5.764s (firmware) + 1.516s (loader) + 1.301s (kernel) + 17.068s (initrd) + 4.801s (userspace) = 30.451s
And the 17 seconds is 16 seconds spent in a password prompt. If
this took 5 seconds longer after I entered my password, I'd be
somewhat annoyed. But only because I just entered my password,
and need to enter it again in the login screen, so I actually
notice this somewhat. If I were not using full disk encryption,
I'd probably not really notice an additional 5 seconds of boottime.
I now spent half an hour writing this email, that annoys me
more.
> >> I think systemd is probably
> >> noticing that the calendar deadline expired while the computer was
> >> off, and interpreting that to mean that the task needs to run as soon
> >> as possible.
> >
> > Sure. And that's exactly what we want (well, actually we'd like to
> > ensure we have networking, but I don't think we have a usable solution
> > for that [which also works at resume]).
>
> I don't understand why you would ever want this run "as soon as
> possible". Can you explain why you consider it a _priority_ task
> under some circumstances?
As I wrote before: Once I am logged in, I want to work with the
device and potentially upgrade my system or stuff. I don't want
apt running in the background fetching stuff (which locks apt
and dpkg, and thus I can't do any package management at all).
Also, if I'm only using the device for a very short time, it
vastly increases the chance of the service running.
Also remember: This is a catch up job. It's not a regular job. You
should catch up as quickly as possible so other stuff relying
on this running daily works.
Furthermore, we are talking about a dependency based boot system, it's
only goal is to boot as quickly as possible (or more precise, to start
as many services as possible as soon as possible). Adding arbitrary
delays to jobs is a bad hack that subverts the very basic principles
behind a dependency based boot manager.
> I will talk to systemd upstream about adding timer features that would
> let one express "once each _calendar_ day, at an arbitrarily chosen
> point, but not immediately upon boot", and we can let this bug lie at
> least till they make a decision about that.
I'm interested in what the systemd people think about timing this
unit in general, our current timer is fairly suboptimal - it's OnCalendar
is every 12 hours at 6, but then we add a random delay of 12 hours,
which is a bit odd (and an AccuracySec=1h, so it could run anywhere
within (6 + 0-12) +/ 1h, that is from 5 to 1. We should constraint
that a bit more. (and we internally have a check to do nothing
if it was already run within the last 24 hours).
JFTR: anacron uses a delay of 5 minutes before catching up with
daily jobs on boot. I don't particularly like the idea of delaying
stuff at boot for modest boot time improvements on older hardware,
it feels wrong.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Reply to: