Ubuntu 16.04 slow boot (apt-daily.service)

Question

My boot is horribly slow, and I don't know why.

$ systemd-analyze 
Startup finished in 10.975s (kernel) + 49.732s (userspace) = 1min 708ms
$ systemd-analyze blame 
         34.971s apt-daily.service
         20.590s snapd.refresh.service
         17.113s grub-common.service
         16.033s apport.service
         16.027s networking.service
         15.894s ondemand.service
         15.860s irqbalance.service
         15.655s speech-dispatcher.service
         11.695s ModemManager.service
          9.772s accounts-daemon.service
          8.626s NetworkManager-wait-online.service
          8.058s systemd-logind.service
          8.053s bluetooth.service
          7.944s gpu-manager.service
          7.896s alsa-restore.service
          7.892s pppd-dns.service
          7.882s rsyslog.service
          7.860s avahi-daemon.service
          7.844s dev-sda1.device
          7.842s systemd-user-sessions.service
          7.648s lightdm.service
          7.610s teamviewerd.service
          6.445s apparmor.service

Also, during boot-up, I see a message that says something like:

device descriptor read/all, error -62
ata1 softreset failed (device not ready) #most of the times
error loading journal #(sometimes)
Test WP failed, assume Write Enabled
Asking for cache data failed     #most of the times
Assuming drive cache: write through

apt-daily.service slows the boot the most. Any idea on how to tackle that?

I have Ubuntu MATE 16.04.

Solution 1

This is Debian bug #844453. apt-daily.service shouldn't be run during boot, but only some time afterward.

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.

Solution 2

The other answer addresses the second block of text in the question.

For me, to solve apt-daily.service taking forever, this Ubuntu Forums post seems to have worked.

issue these commands as an example of how to edit /etc/systemd/system.conf

sudo cp /etc/systemd/system.conf /etc/systemd/system.conf.bak 

That will make a back-up for safety.

gksudo gedit /etc/systemd/system.conf 

Look for and change these 2 lines:

#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s 

Mine now look like this:

DefaultTimeoutStartSec=10s 
DefaultTimeoutStopSec=10s 

Been doing that for year now and nothing bad has come of it.

Remove the leading #'s which disable the line, and change the value.

Solution 3

If it's a desktop, open it and disconnect then reconnect All HDD cables including MB.

Failing that, it sounds like your HDD is timing out. BACKUP all data now.

Burn Live network install of Ubuntu to suite your system, boot to Try Ubuntu. Then run Gparted: by default it checks for HDD read errors. If you have a backup of all your data maybe someone else could advise.

Comments

[Muhammad Gelbana]

Does this apply to any of the services listed by the systemd-analyze blame command ?

[zwol]

@MuhammadGelbana I don't understand what you are trying to ask me.

[Muhammad Gelbana]

I'm asking if I can run a similar command such as sudo systemctl edit snapd.refresh.timer and add the same text you posted in your answer to override the timer configuration for snapd.refresh ?

[zwol]

It should work for anything that is actually a "timer", yes, but not for arbitrary services started on boot.

[Yuri Gor]

I could not boot with this timeouts and had to comment this lines back from recovery mode.

[cat]

@YuriGor my apologies, i guess something changed since 16.10

[Yuri Gor]

Mine is 18.04. I don't remember clearly, but it was an issue related to sda, so probably my hdd takes too long to mount or whatever.

[openCivilisation]

If I wanted to automate this config change, is there a way to do it directly to a file path instead of systemctl edit?

[zwol]

@openCivilisation Yes, create /etc/systemd/system/apt-daily.timer.d/override.conf and put the text shown there -- which is exactly what systemctl edit does. You'll have to run systemctl daemon-reload or reboot afterward. See serverfault.com/questions/840996/…

[openCivilisation]

Thanks for sharing. Why wouldn't it also be required to change the daily upgrade timer as well?

[zwol]

@openCivilisation You should ask a new question about that.