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.



5 Answers 5


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.

  • 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
    Commented Oct 13, 2020 at 6:40
  • 4
    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. Commented Sep 22, 2021 at 14:17
  • 4
    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_
    Commented Sep 13, 2022 at 8:58

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
  • 1
    Perfect!!! There are several verbose solutions but this one works like a charm! Commented Jul 9, 2021 at 17:13
  • 6
    What if sudo systemctl stop ... never terminates? Commented Aug 20, 2021 at 8: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
    Commented Apr 10, 2022 at 2:42
  • @stackprotector I had to sudo kill it... not sure what it lefts broken
    – Juh_
    Commented Sep 13, 2022 at 8: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
    Commented Feb 16, 2023 at 17:10

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

  • 1
    Good option, as it's clear how to re-enable it, if desired.
    – gbarry
    Commented Feb 15, 2022 at 1:42

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

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's doing 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 its 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).
  • 2
    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 ;\ Commented Nov 6, 2019 at 0:52
  • Use case should be part of the Question.
    – user535733
    Commented Nov 6, 2019 at 1:43
  • added usecase in the question as requested Commented Nov 9, 2019 at 16:49
  • 11
    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
    Commented Oct 10, 2020 at 17:10
  • @PeterMortensen edited. Thanks for the suggestion.
    – user535733
    Commented Nov 1, 2021 at 0:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .