Bug#844453: apt-daily.service delays startup by more than five minutes
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, 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...
(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.)
> 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?
> 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.
Reply to: