Shorten boot time "apt-daily.service"

I was getting a long boot up time of about 2 minutes.

I ran systemd-analyze blame. (the blame part is cute.)

You should not see apt-daily-service in the listing.

I found a fix that shortened that time by 30 seconds.

This was the tip that worked.

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


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.


Thanks, that saves some boot time indeed.

Thanks for the tip, had already noticed the apt-daily.service running at boot on one of my laptops. This helped.

You are most welcome.

I like to see what terminal commands are supposed to do so I investigated. This command creates a directory called apt-daily.timer.d under /etc/systemd/system/ with (if you know joe commands) a file named override.conf with -


this text in it. No particular help that I can see if you use an SSD drive but quite useful otherwise. Thanks for the tip and for posting where you got it.

1 Like

Which will change the timing of unit file /lib/systemd/system/apt-daily.service
which will exec Python script /usr/lib/apt/apt.systemd.daily
which has a configuration file /etc/apt/apt.conf.d/10periodic

which in my system contains:

APT::Periodic::Update-Package-Lists “1”;
APT::Periodic::Download-Upgradeable-Packages “0”;
APT::Periodic::AutocleanInterval “0”;

which means (the Update-Package-Lists bit) “apt-get update” will be run automagically every day.

So: if apt-daily.service runs at boot before network connection is established, it will have to wait for the connection before it can “apt-get update”.

Which, of course, will increase the boot time (“slow down boot”), no matter how fast the hard disk is.


Your full explanation is great! Thanks for taking the time to write this out samuvuo.

I don't know if this is because of changes since the OP or not, but this (conceptually very valuable) workaround is basically broken. If the machine was off at the time systemd WOULD have run the job, it will be run at startup regardless of this timer change, blocking logins again.
The same goes for mandb (seriously?!).

IDK yet if there's a sensible way to fix this, but I expect not. The "but they run in parallel" argument is basically false here, because the IO flood from the two of them is enough to block anything else from being able to operate at all, if the machine is using an HDD.
I'm surprised they're not using ionice -c 3 (or at least, don't seem to be, judging by the 30+ seconds they're blocking login for), but that would probably be the best way to deal with them.