29

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

user3450548
  • 423
  • 1
  • 4
  • 9

5 Answers5

39

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.

James
  • 518
  • 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 06:40
  • 3
    It's a critic response towards unattended-upgrades but sadly is true. This service is probably poor designed and lot of times I find my virtual machines broken by unattended-upgrades mess. Most of the times it keeps your machine updated but there are various times where it breaks everything. I'm starting to think that a cronjob sudo apt-get updates && sudo apt-get upgrade -y could work better in some cases... Not voting it directly as answered because I need a solution to terminate one time unattended-upgrades and cast the updates commands manually, however you got a point. – user3450548 Sep 22 '21 at 14:17
  • 3
    I went happily back from windows (from work) to linux after a few years, and it starts an auto-update!!! When did linux word decide to do the same stupid things as private OS :( – Juh_ Sep 13 '22 at 08:58
22

None of these solutions will work if unattended-upgrades is still running. You will get this error:

E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

You have to stop the service before you can uninstall/remove it. To do that:

sudo systemctl stop unattended-upgrades

Then get rid of it:

sudo apt-get purge unattended-upgrades
The_M
  • 259
  • 1
    Perfect!!! There are several verbose solutions but this one works like a charm! – shiv chawla Jul 09 '21 at 17:13
  • 6
    What if sudo systemctl stop ... never terminates? – stackprotector Aug 20 '21 at 08:19
  • 1
    Adding to that, you could disable it so that it doesn't come back at the next boot: systemctl disable unattended-upgrades.service instead of a purge. – Déjà vu Apr 10 '22 at 02:42
  • @stackprotector I had to sudo kill it... not sure what it lefts broken – Juh_ Sep 13 '22 at 08:59
  • This should be the accepted answer, as merely apt remove as the above answer will still leave the process running, and sudo pkill unattended-upgrade-shutdown won't even be able to kill it (it was OK to kill before, but not with the latest version in Ubuntu 22.04.1). – xpt Feb 16 '23 at 17:10
9

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

Pablo Bianchi
  • 15,657
5

Copy paste solution could be also this one:

sudo systemctl stop unattended-upgrades

If it still running:

sudo pkill --signal SIGKILL unattended-upgrades

Disable service and change config:

sudo systemctl disable unattended-upgrades
sudo sed -i 's/Unattended-Upgrade "1"/Unattended-Upgrade "0"/g' /etc/apt/apt.conf.d/20auto-upgrades
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 5-10 minutes until apt completes it's task. Good time for a sandwich.

  • 5-10 minutes really means that. Be patient. The time to get concerned and seek help is if apt seems to make no progress for, say, 20 minutes or more. (20 minutes is not a rule -- that's my personal guideline).
user535733
  • 62,253
  • 1
    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 06 '19 at 00:52
  • Use case should be part of the Question. – user535733 Nov 06 '19 at 01:43
  • added usecase in the question as requested – user3450548 Nov 09 '19 at 16:49
  • 10
    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
  • @PeterMortensen edited. Thanks for the suggestion. – user535733 Nov 01 '21 at 00:27