39

The startup with 18.04 seems to take a bit longer than 17.10 so I ran systemd-analyze blame and found that apt-daily.service and apt-daily-upgrade.service are taking up over three minutes between them.

:~$ systemd-analyze time
    Startup finished in 9.173s (kernel) + 3min 30.201s (userspace) = 3min 39.375s
    graphical.target reached after 15.268s in userspace
:~$ systemd-analyze blame
    1min 52.265s apt-daily-upgrade.service
    1min 27.579s apt-daily.service
          6.603s NetworkManager-wait-online.service
          5.105s plymouth-quit-wait.service
          1.517s plymouth-start.service
          1.439s dev-sda1.device.............

So, what are these services actually doing (checking apt is up to date I imagine), why do they take so long and do I really need them to run on every bootup?

Improve this question
1
  • 2
    See Debian Bug #844453 for a complete explanation of the issue, and current work in progress to fix.
    – user535733
    May 22, 2018 at 11:48

3 Answers 3

Reset to default
33

You can decide it by yourself. But on my systems (mainly 16.04 LTS) I have disabled both with:

sudo systemctl disable apt-daily.service
sudo systemctl disable apt-daily.timer

sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl disable apt-daily-upgrade.service

Because of the fact that some functionality on desktop is provided by update-manager and
I do not want to get error messages about lock-files in archives or lists directories whenever I run apt manually.

Improve this answer
4
  • Will this work in 18.04 as well? Could it help in my issue here? And have these commands to be run just once and their effect will be retained after a reboot?
    – DK Bose
    Sep 30, 2019 at 15:30
  • @DKBose it should only for apt-daily part. The xapian part is driven by cron.weekly.
    – N0rbert
    Sep 30, 2019 at 15:35
  • OK but it appears that update-apt-xapian-index is running daily and around the same time as the apt-daily services. Anyway, I will run those commands tonight and see what happens tomorrow.
    – DK Bose
    Sep 30, 2019 at 15:41
  • For anyone hitting utterly baffling "dpkg: error: dpkg status database is locked by another process" errors and thinking "But unattended upgrades are not enabled, why is the dpkg database ever getting locked implicitly?", it helps to know that salsa.debian.org/apt-team/apt/-/blob/master/debian/… includes an unconditional apt-get check call to ensure the timer can lock the package DB (even if it doesn't need to).
    – ncoghlan
    Jun 12, 2020 at 3:55
4

You can change the timer of the service, it should run after the boot, actually. Here's the solution.

Ubuntu 16.04 slow boot (apt-daily.service)

As a workaround, do sudo systemctl edit apt-daily.timer and paste the following text into the editor window:

# apt-daily timer configuration override   
[Timer]   
OnBootSec=15min   
OnUnitActiveSec=1d   
AccuracySec=1h   
RandomizedDelaySec=30min

This changes the "timer" that triggers apt-daily.service to run at a random time between 15 min and 45 min after boot, and once a day thereafter. See the systemd.timer manpage for additional (not very well written, alas) explanation of what this means.

If this is not working, create/edit the file in /etc/systemd/system/apt-daily.timer

Improve this answer
1
  • This doesn't work. Dealing with all this systemd nonsense has been one exercise in frustration after another. There seems to be no way do delay atp.daily.timer.
    – mikewhatever
    Nov 20, 2020 at 8:26
3

Yes, it is important, you need it.
If spending internet data is a concern to you like it is to me, you may not want it to be started so often.
But that is useful to keep your OS secure by keeping packages updated.

Now about the slow startup, others already answered how to workaround that :)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .