4

It happens often that when I boot my Ubuntu 18 machines and I want to manually update my software I get stuck into errors involving something already using apt (endless waiting unattended-upgrades and / or other services).

Most of time with machines or virtual machines that are not booted frequently, where a boot and the next are followed by many days or 4-5 months, meanwhile maybe some certificates, mirrors or somethings else has changed and unattended-upgrades just get stuck on endlessy timeouts trying to contact servers that are not there anymore..

This is the error:

user@ubuntu:~$ sudo apt-get upgrade
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarly unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

I would like to know if there's a command line to gently terminate all instances using apt, leave the apt environment and configuration in a coherent state and be ready to use the gui version of ubuntu Software Updates or apt-get.

Thanks

2

The long term solution to your problem is easy:

sudo apt remove unattended-upgrades

There is, in my opinion, no excuse for the poor design of unattended-upgrades. Blocking every software install, and even system shutdown, for hours with an automatically initiated process that a user cannot shut down without risking corrupting the apt database: the mind boggles.

In the short term, you can either wait and hope, or send it a SIGKILL and hope for the best - it will be OK if it is either taking a long time to download, or is stuck because of a missing certificate, faulty connection, or one of the million other reasons unattended-upgrades can trip over its own shoelaces. You may need to manually remove the lock file.

After that, hurry up and uninstall unattended-upgrades to regain control of your computer.

1
  • That's why I write that you may need to manually remove the lock file once after killing the stuck unattended-upgrades process, and then uninstall the poorly thought out program first thing after that. Note that unattended-upgrades will stall for any number of reasons, including just a slow connection to one of the servers, but a stuck lockfile is also no excuse. It is simply poorly designed for a system process out of user control to block normal operation of the computer for extended periods of time for whatever reason. System processes must be designed with fault mitigation in mind. – James Oct 13 '20 at 6:40
2

There's an irony of you wanting to do a manual upgrade: Unattended Upgrades is already doing exactly that for you. When systemd detects that your newly-booted system has missed it's apt-update and apt-upgrade timers, it promptly triggers them.

  • For most users, simply let those jobs complete -- it what you wanted to do anyway. Monitor ps or /var/run/apt/periodic to find out when Unattended Upgrades finished it's work.

However, for your use case of long periods between booting, consider editing /etc/apt/apt.conf.d/20auto-upgrades to disable automated updates and upgrades. We recommend against most users disabling merely so they can upgrade manually...folks tend to slack on that method after a few weeks.

Making Unattended Upgrades abortable is possible, but it's NOT RECOMMENDED for most general purpose users.

Edit /etc/apt/apt.conf.d/50unattended-upgrades to enable this option:

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGTERM. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "false";

Obviously, you must have a clear understanding of how to use SIGTERM.

Note that the same file has a setting to move Unattended Upgrades to shutdown (like Windows).

Alternately, automated updates and upgrades use systemd timers. You can change the time at which they run by simply editing /lib/systemd/system/apt-daily.timer and /lib/systemd/system/apt-daily-upgrade.timer. Remove the randomization and specify the constant time you wish.

For General Purpose Users: You probably don't need any of these tools, but they are available. In general, DO NOT INTERRUPT APT under most circumstances. Doing so inexpertly WON'T release the lock, and may damage your system. Cleaning up after an apt breakage can be confusing and tedious...and is completely avoidable. For most users (including experts), best practice is to simply wait until apt completes it's task. Good time for a sandwich.

4
  • It happens most of times with machines and virtual machines where there's a lot of days between one boot and the other. Maybe lot of things changed, certificates revoked, remote server changes, practically If i kill the service and cast an apt-get update manually everything works ok but unattended upgrades just do mess. In my experience unattended upgrades works fine just if you regularly run the machines day by day.. if there's too much time in days between one boot and another it get stuck ;\ – user3450548 Nov 6 '19 at 0:52
  • Use case should be part of the Question. – user535733 Nov 6 '19 at 1:43
  • added usecase in the question as requested – user3450548 Nov 9 '19 at 16:49
  • Why would you ever not want it broken down into smaller steps that can be terminated without leaving the database in shambles? Why would the user ever want an interminable process blocking our ability to install software or shutting down for hours? Did someone look at Windows forcing an upgrade in the middle of an important presentation and think "This is what Linux needs!"? – James Oct 10 '20 at 17:10
0

Using dpkg for some ASCII-GUI configuration is another option (or at least I think it hasn't been mentioned so far):

sudo dpkg-reconfigure unattended-upgrades

Then just select No, press Enter. In my case, this has promptly stopped the ongoing unattended upgrade that seemed blocked (at least as promptly as the hardware seemed to allow :) ).

This information was found here (kudos): How To Disable Unattended Upgrades On Ubuntu

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.