Does anyone know if it is possible to determine the status of an unattended upgrade? Is it possible to find out which packages are being installed or where we are in the process?

I appreciate the benefit of unattended upgrades, but they can be really annoying when you have a system that's been off for a couple months, and you want to install an application or when they're eating CPU resources on machines that don't have much to begin with.

I'm not simply looking to kill the unattended upgrades. I know how to do that. I want them to run. I just want to know how I can find out what's actually going on and what phase they're in.

  • Run pgrep -fl apt, I suppose. – muru Jul 10 '17 at 14:33

On a 16.04 and newer systems, unattended-upgrades runs daily at a random time.

How to tell when unattended upgrades will run today:

The random time is set by a cron job (/etc/cron.daily/apt.compat), and you can read the random time for today by asking systemd:

$ systemctl list-timers apt-daily.timer
NEXT                         LEFT     LAST                         PASSED      UNIT            ACTIVATES
Tue 2017-07-11 01:53:29 CDT  13h left Mon 2017-07-10 11:22:40 CDT  1h 9min ago apt-daily.timer apt-daily.service

In this case, you can see that u-u ran 1 hour and 9 minutes ago.

How to tell if unattended upgrades are still running:

One easy way is to check the timestamp files for the various apt components:

$ ls -l /var/lib/apt/periodic/
total 0
-rw-r--r-- 1 root root 0 Jul 10 11:24 unattended-upgrades-stamp
-rw-r--r-- 1 root root 0 Jul 10 11:23 update-stamp
-rw-r--r-- 1 root root 0 Jul 10 11:24 update-success-stamp
-rw-r--r-- 1 root root 0 Jul 10 11:24 upgrade-stamp

You can see here that u-u is just another apt component. apt places the timestamp here regardless of how the apt was started.

Putting the data together, you can see that the timer started apt (u-u) at 11:22. It ran an update which completed at 11:23, then an upgrade which completed at 11:24. Finally, you can see that apt considered the upgrade to be a success (no error or other failure).

Obviously, if you see a recent timer without a corresponding completion timestamp, then you might want to check ps to see if apt is still running.

How to tell which step apt is running right now:

One easy way is to check the u-u logfile.

$ less /var/log/unattended-upgrades/unattended-upgrades.log
2017-07-10 11:23:00,348 INFO Initial blacklisted packages: 
2017-07-10 11:23:00,349 INFO Initial whitelisted packages: 
2017-07-10 11:23:00,349 INFO Starting unattended upgrades script
2017-07-10 11:23:00,349 INFO Allowed origins are: ['o=Ubuntu,a=zesty-security', 'o=Ubuntu,a=zesty-updates']
2017-07-10 11:23:10,485 INFO Packages that will be upgraded: apport apport-gtk libpoppler-glib8 libpoppler-qt5-1 libpoppler64 poppler-utils python3-apport python3-problem-report
2017-07-10 11:23:10,485 INFO Writing dpkg log to '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log'
2017-07-10 11:24:20,419 INFO All upgrades installed

Here you can see the normal daily process, including the 'started' and 'completed' lines, and the list of packages that were about to be upgraded.

If the list of packages is not logged yet, then apt can be safely interrupted. Once the list of packages is logged, DO NOT interrupt apt.

Since you have a resource-constrained environment, be aware that apt can be configured many ways to work reliably and unobtrusively with different run times, nice levels, bandwidth limits, and many other useful settings.

  • 10
    This command shows as if your running in terminal if it hasn't completed. tail -f /var/log/unattended-upgrades/unattended-upgrades-dpkg.log – Adsy2010 Jul 28 '19 at 14:14
  • When this happens and I think the software updater is hung, it's merely that my attended (interactive) update is waiting for the same update that is already installing in the background. Probably it would be nice instead of showing the "Waiting for unattended upgrades", the UI in the foreground just showed that it's doing installs and did the tail -f thing for us. – Warren P Mar 15 at 19:40
  • @WarrenP since both use apt, whichever started second will simply fail -- it won't be able to get the apt lock. Consider opening a new question for whatever problem you are having. – user535733 Mar 15 at 19:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.