Bug#844453: apt-daily.service delays startup by more than five minutes
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.
>> 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?
>> 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.
This makes sense.
> 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.
... This doesn't. Why do you care about that?
> 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.
... Huh, I had thought SSDs were still US$1/GB, but they're less than
half that now.
They are still a nontrivial expense and, since we're talking about
replacing the boot drive, a nontrivial upgrade job, I don't think it's
fair to say that software changes to improve boot performance are
unnecessary because "you can just switch to appropriate hardware."
> 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).
OK, this is a really good point. I had missed the paragraph of the
systemd.timer manpage where it says that OnActiveSec doesn't count
time in suspension.
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.
zw
Reply to: