Bug#844453: apt-daily.service delays startup by more than five minutes
On Mon, Mar 27, 2017 at 12:15:38PM -0400, Zack Weinberg 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, 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.
Note that blame is completely useless to measure the actual
boot performance, just like analyze is. You don't really care
that all services have started, you care that the services you
are using have started - other services running in the background
are basically speaking irrelevant.
There might be something entirely else going on and you are blinded
by this nonsense :)
>
> 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.
>
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]).
You are free to override the settings via drop-in files in
/etc/systemd/system/apt-daily.timer.d/YOURSETTINGS.conf
I don't think this behavior is new: That's basically the same thing
anacron used to do back with the cron job. It now happens regardless
of anacron being installed, obviously, so if you don't want anacron
like persistence, disable it.
> > 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?
I think so, yes. I have days I reboot a lot, I would not want to
have my service run every time I boot.
I want to run the service as soon as possible if the timer elapsed
and there is connectivity. The reason is simple: By the time I login,
I want the service to be done.
>
> > 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?
Not that I know of.
IMO: It's kind of ridiculous to care about boot speed and use a hard disk
at the same time, so I always fail to see the point in that. SSDs are priced
acceptable now, and the boot performance increase is 6 times or more, so
I don't really care if you take 1 minute or 2 minute to boot if you could
boot in 10 seconds just by switching to appropriate hardware.
> > 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.
The point is that with the real time thing, systemd stores when
it last executed the service and on boot/resume checks if the service
needs to be run.
So, let's say you have a laptop you use every day for 4 hours, and then
suspend. With OnActiveSec, the service would run after about a week
(-/- 3 days). With OnCalendar, it will run daily (maybe every second
day, let's say it schedules Mon 18, Tue 14 and you boot on Mon 16-20
and Tue 08-12. It would not run on Tuesday then, but it would immediately
catch up on Wednesday and schedule the next run within the next
24 hours +/- 12).
And that increases even more if you use the device less: If you just
check emails for half an hour each day, it would take about 1.5 months
for the service to run with OnActiveSec, but it's still the same with
OnCalendar.
And that makes a huge difference.
--
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: