On Mon, 27 Mar 2017 12:15:38 -0400 Zack Weinberg <za...@panix.com> wrote: > On Mon, Mar 27, 2017 at 10:49 AM, Julian Andres Klode <j...@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