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?

muru
  • 197,895
  • 55
  • 485
  • 740
SteveInBavaria
  • 3,339

3 Answers3

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.

N0rbert
  • 99,918
  • 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 '19 at 15:30
  • @DKBose it should only for apt-daily part. The xapian part is driven by cron.weekly. – N0rbert Sep 30 '19 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 '19 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 https://salsa.debian.org/apt-team/apt/-/blob/master/debian/apt.systemd.daily 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 '20 at 03: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

gman
  • 2,276
  • 4
  • 27
  • 39
overkill22
  • 171
  • 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 '20 at 08: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 :)

Pablo Bianchi
  • 15,657
Aquarius Power
  • 4,011