Bug#844453: apt-daily.service delays startup by more than five minutes
On Mon, 27 Mar 2017 12:15:38 -0400 Zack Weinberg <zackw@panix.com> wrote:
> On Mon, Mar 27, 2017 at 10:49 AM, Julian Andres Klode <jak@debian.org> wrote:
> > On Mon, Mar 27, 2017 at 10:12:59AM -0400, Zack Weinberg wrote:
> >>
> >> I believe an appropriate fix for this bug would be to change
> >> apt-daily.timer so that systemd does not attempt to run APT
> >> daily background processing during boot-up, but only some time
> >> afterward.
> >
> > The problem is that we do not really want to run it at boot.
>
> Well, it _is_ run at boot, and in fact _blocks_ boot,
Does it really block boot? Note that the output of `systemd-analyze
blame` is particularly annoying, since apt-daily.service running at
boot does not prevent you logging in or doing other stuff. In fact, if
you do `systemd-analyze blame $some_service_I_actually_care_about`,
apt-daily is unlikely to be there.
> 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...
>
> There probably are some circumstances where the current spec doesn't
> cause it to be run at boot, but it does consistently run at boot when
> I turn my desktop on in the mornings: 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.
>
> Maybe that's a systemd bug or at least a feature request, but it's too
> late to get a feature request through for jessie...
I'd like some evidence that the boot is actually blocked though.
apt-daily does not specify any ordering requirements so it should not
interfere with the boot. Maybe apt-daily could gain a
After=multi-user.target so that it does not run while booting, but
that may have adverse side effects (eg, making the time window after
boot where one can't apt-get update longer).
>
> (And see https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image
> for a case where this is not just a performance issue.)
apt-daily.service could gain After=cloud-config.target to play nice
with cloud-init. Or cloud-init could gain the inverse Before=.
>
> > We might want to delay startup if systemd would start it otherwise,
> > but adding a rule to always start it at a boot is a step in the
> > wrong direction.
>
> I think you're saying this because what you _really_ don't want is for
> the task to be run _more_ than once daily. If the computer is
> rebooted several times within a day, it shouldn't get run each time.
> Is that right?
>
> > That said, I'm not convinced that apt's daily service significantly
> > slows down a boot process, at least not on a solid state drive. Using
> > a spinning disk generally conflicts with systemd's model of starting
> > as much as possible in parallel
>
> SSDs are still not the common case, and should not be optimized for at
> the expense of spinning disks. Is there a way to tell systemd to cool
> it a little?
There was systemd-readahead but it was stripped from systemd upstream
and nobody stepped up to maintain it separately.
>
> > And OnUnitActiveSec is wrong. We want to run daily (in real
> > time), not after your machine was on for 24 hours
>
> I don't understand. Once the computer has been on for 24 hours these
> become the same thing. Conversely, if the computer is not left on for
> more than 24 hours at a time (the common desktop case) then it's a
> matter of luck (and the user's schedule) whether the timer ever gets
> to fire "naturally" while the computer is on.
But (as you noted earlier), rebooting causes a run of the service, and
short-lived boots would never run (ie, start machine and power down
before an hour has elapsed).
Saludos
Reply to: