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.
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.
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 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.
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.