I get this error when trying to use apt-get:

E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?  

How can I fix this?

Volker Siegel
  • 12,422
  • 5
  • 43
  • 65
La Ode Adam Saputra
  • 11,833
  • 3
  • 15
  • 8
  • 20
    This is also true if you reboot? Maybe some old apt thread is locking the file, you need to find out which and kill it or just rebooting will do it. – Bruno Pereira Jan 29 '12 at 11:19
  • yes, even after reboots im getting the same responses. Do you know how can I find which apt thread is locking the file?. Thank you! – kern Jan 29 '12 at 11:25
  • 4
    [This procedure](https://help.ubuntu.com/community/PackageManagerTroubleshootingProcedure) almost always fixes this problem, and when it doesn't, its output (the text from the Terminal) is sometimes useful. If you decide to do it, you can add this text to your question. – Eliah Kagan Jun 06 '12 at 09:10
  • 1
    I would suggest one more thing that you may note when faced with this issue. Do check if your disk drives are mounted. If they are not, you may not be able to acquire the lock as the package installer will not be able to access the filesystem. Hope this helps. :) – Hari Apr 06 '13 at 12:23
  • 61
    You can use `sudo lsof /var/lib/dpkg/lock` to find the process that owns the lock file (if empty, assume the lock is left over from a previous boot and can be `sudo rm`d), then consider doing a `sudo kill -9 ` (get from `lsof` output. – waltinator Mar 17 '14 at 22:01
  • 1
    This is old, but I'm noticing your original question doesn't indicate you are running this as root or via `sudo`. – tedder42 Dec 15 '14 at 16:55
  • 12
    This can be a sign that something else is installing or removing software and has locked the apt database while it performs the actions. – Foreever Feb 03 '15 at 04:32
  • For me, rebooting did solve it. – Sithu Feb 07 '15 at 10:07
  • 1
    I don't think much of any of the answers here. It might be better to find out which process has the lock and kill that process. See this for more info: http://ubuntuforums.org/showthread.php?t=1858466 – user3728501 Oct 10 '15 at 18:45
  • So this happens to me all the time and the solutions is simpler as check if you have Synaptic Package Installer open while trying install in terminal. – T04435 Feb 25 '16 at 00:11
  • 1
    If the lock is caused by apt-daily.service, then try https://askubuntu.com/a/878982/288250 – Foreever Apr 25 '17 at 13:45
  • It was just the software updater. But by RDP it is found in the Applications, Settings menu. Once it came up and was stopped, then all was well. – SDsolar Sep 15 '17 at 07:20
  • restart fixed it for me – maracuja-juice Oct 26 '17 at 08:36
  • It happened right after reboot for me. There was a dkpg already running probably to auto-update software. I waited until it was done. Then I could install. – latj Apr 07 '18 at 08:15
  • Running `sudo pkill apt-get` worked for me. – MAChitgarha Jul 16 '18 at 05:59
  • This happened to me, and it turned out that Ubuntu was waiting patiently in the background for me to go ahead with updates (Software update icon visible in the launcher bar). Once I did this and it completed, I was able to continue using apt-get without issue. – witenitenz Aug 31 '18 at 23:13
  • OK so I had the same problem BUT here's the deal: I didn't notice that the "'There are updates available', install, cancel, remind me later"-window was open in the background. So I closed it and then it worked. – Phillip Sep 05 '18 at 17:40
  • 8
    On my Ubuntu 18.04 VM there is a process called unattended-update, which is runned by a process like `root 0 15:58 ? 00:00:00 /bin/sh /usr/lib/apt/apt.systemd.daily lock_is_held install`, which seems to run apt update every time I turn the machine on. Depending on the size of the update (which often corresponds to how long ago since I used that machine the last time), this can use from 1-10 minutes to complete. After that, the lock is freed for manual apt installs and updates. Try: `sudo ps aux|grep apt` or `sudo ps aux|grep unattended. – Kjetil S. Dec 15 '18 at 15:19
  • The first thing you should do is to check if some other program could be running system update or installing a program. If you are using command line, check if an application like Software Center, Software Updater, Synaptic, Gdebi is running any update/installation. If that’s the case, If there is no such application running, please check all the open terminal windows and see if you are running an update or installing a program. If yes, wait for it to finish.If none of the above is happening, check which other process is running the apt command – Sachin Kumar May 20 '20 at 09:20
  • If you've just started up your machine, I strongly recommend @poolie's answer below https://askubuntu.com/a/15440/1115972 .tl;dr WAIT a few minutes to let the auto-updater finish its work, then try again. – RealHandy Sep 14 '20 at 17:35
  • For me, waiting a few minutes solved the problem -- I'd been trying to `apt upgrade` just after boot. – mathandy Oct 26 '21 at 06:30

25 Answers25


This should be used as last resort. If you use this carelessly you can end up with a broken system. Please try the other answers first before doing this.

You can delete the lock file with the following command:

sudo rm /var/lib/apt/lists/lock

You may also need to delete the lock file in the cache directory

sudo rm /var/cache/apt/archives/lock
sudo rm /var/lib/dpkg/lock

After that, try opening Synaptic again.

Elder Geek
  • 34,568
  • 25
  • 89
  • 173
  • 10,837
  • 1
  • 19
  • 21
  • 18
    ok... but why happened this? – Jaime Hablutzel May 26 '12 at 22:40
  • 46
    @jaime: probably apt-get (or some GUI frontend to it) was halted while executing, leaving apt in a locked state. – bouke Sep 13 '12 at 12:15
  • 9
    @AnwarShah no, there are other considerations before going around removing files of the system. – Braiam Dec 31 '13 at 14:47
  • 26
    rm /var/lib/dpkg/lock; dpkg --configure -a: – WitchCraft Jan 15 '14 at 15:07
  • Well its have some change. sudo rm /var/lib/dpkg/lock. – mahendra Mar 22 '16 at 07:44
  • 1
    This doesn't work. I still get the same error! – IgorGanapolsky Jul 24 '16 at 20:47
  • @bouke....you are correct. I have faced something similar today for time being. I have given command to open Google Chrome and also "sudo ap-get update" command same time. After opening Google Chrome, lock becomes available. – ni8mr Nov 11 '17 at 03:11
  • I type sudo rm lock from it's directory and it remains there like the undead – user391339 Feb 23 '18 at 03:48
  • Thank you. This should only be attempted when any `apt` and `dpkg` instance have been killed. In my case I interrupted the process so I had to manually remove the locks. – Rolf May 13 '18 at 15:09
  • happened when I awoke a suspended vagrant box and the `up` failed. ran `reload` and got this error message when I tried to install a package, deleting the lock fixed it – chiliNUT Feb 09 '19 at 07:05
  • 3
    Argh, please no, never recommend removing the lock files! This is a sure way to damage your package managers databases. :/ The presence of this files does not indicate that a process is locking them. Some time ago I added an entry to the dpkg FAQ explaining this given that the Internet seems to be filled with incorrect advice: https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_can_be_done_when_the_dpkg_lock_is_held.3F. In addition we have improved both dpkg and apt to print a more detailed error message with the process holding the lock and apt now waits by default for the lock to be released. – Guillem Jover Dec 25 '21 at 19:01

(Note: my original answer was extensively edited by Guillem Jover, the primary dpkg developer.)

I see pretty much all the answers recommend deleting the lock. That must never be done, it is always preferable to kill dpkg (which is supposed to be resilient against that kind of event), than to even think about removing its lock file (where its presence does not indicate the lock being held). The locks are acquired when a dpkg or an apt process is running, and are released (by the kernel if necessary) when the processes complete or are killed. Newer dpkg and apt versions will print the PID of the process holding the contended lock file, and apt now even waits by default for the locks to be released. This is covered in the dpkg FAQ.

If you try:

sudo fuser -vik -TERM /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend /var/lib/apt/lists/lock
sudo dpkg --configure --pending

that will prompt to terminate any process currently holding these lock files, which, once killed will get the locks released. If you see an apt-get process or an aptitude process that looks stuck, killing them should be less harmful than when the packaging system is in the middle of a package installation. If the processes are really stuck and you have no other choice, you might need to kill them by passing -KILL instead of -TERM. You then need to finish any pending configuration so that dpkg can get those into a better state, and so that it can also integrate updates to its journal to the main status database.

Killing a dpkg process directly, if present, is in general not a great idea, because if dpkg is active, some maintainer script might be performing actions that are not resilient against abrupt termination (or crashes), but dpkg internally should be resilient to such abrupt terminations, and it's preferable to do that, than to remove any lock file, which has a way higher chance of damaging both the dpkg database and the filesystem.

Killing a frontend such as an apt-get or aptitude process, while not ideal, is in general much safer.

Faheem Mitha
  • 7,701
  • 1
  • 14
  • 18
  • 1
    Also, I would kill dpkg. This worked for me, as it was trying to finish something it stared before the machine was stopped previously, and couldn't figure it out on his own. – morynicz Sep 14 '13 at 18:46
  • 23
    @Link I don't think killing `dpkg` is a good idea, because usually `dpkg` is manipulating the package database directly, and this could cause corruption. – Faheem Mitha Sep 14 '13 at 20:17
  • There was no need to kill `dpkg`. After killing the stuck `apt-get` process, `dpkg` went away automatically. – friederbluemle Oct 03 '14 at 04:16
  • 23
    If killing dpkg can corrupt its database, dpkg was badly designed. Period. – Jay Sullivan Nov 18 '14 at 03:36
  • 12
    for me, this resulted in an error `dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.` when running `sudo apt-get dist-upgrade` again. Running the command then resolved the issue. I love Nix! – Wayne Phipps Jun 26 '15 at 13:17
  • 7
    Note, `killall apt-get` does the same thing as your `ps`/`kill` combo. – Cerin Jan 15 '16 at 22:09
  • Should I kill `aptd`? – jvriesem Aug 08 '16 at 18:30
  • 4
    Note that I found that I needed to run `sudo dkpg --configure -a` after killing the rogue apt process in order for things to return back to normal. – starbeamrainbowlabs Oct 17 '16 at 18:35
  • 2
    Easiest way to know the process which is doing trouble `ps -e | grep -e apt -e adept | grep -v grep` then run sudo kill num eg `sudo kill 2304` – Fakabbir Amin Dec 31 '16 at 16:11
  • 2
    I experienced the same issue and in my case the problem was the ubuntu unattended upgrades. the same issue is talk about [here](https://github.com/boxcutter/ubuntu/issues/73#issuecomment-231679733). also you could also `apt remove unattended-upgrades`. – machineaddict Feb 13 '17 at 19:47
  • 1
    In my case it was automagically solved after second or third reboot, but not after the first one... o.O? Anyway, do try to complete processes (e.g., `sudo dpkg --configure -a`) and other harmless things (e.g., opening and closing software center, synaptic, software updates, etc.) before killing running processes. And try killing processes before force-deleting the lock, risking to break your system. – FairMiles Jun 21 '17 at 12:18
  • 2
    Don't `ps .. | grep ..` because it will match grep. Instead use `pgrep -f dpkg` and `pkill -f dpkg` – dhchdhd Sep 12 '17 at 21:38
  • 2
    In the list of my processes I spotted a `usr/lib/apt/apt.systemd.dayly install`. Figured I just had to give it some time and try again. It worked. I spared a process life and found a peaceful solution to my problem. – raggot Feb 16 '18 at 08:31
  • How do I know processnumber? Plz more precisely.. – creator Mar 06 '18 at 00:14
  • @FaheemMitha similar to @Barry I suggest using `pgrep -a apt` instead. – Pablo Bianchi Apr 26 '18 at 17:29
  • 2
    @PabloBianchi There's no reason to use `pgrep` here. This answer isn't showing an automated or scripted approach, a human is involved. So `ps` or `pgrrp -a` are as good as each other. – terdon Apr 28 '18 at 12:14
  • @terdon You don't need to be using an automated or script to use `pgrep`. The difference isn't extremely important, but it's better because doesn't match grep (even better with [`-r`](https://askubuntu.com/a/185746/349837)). `ps`+`grep` is kind a hack, [`pgrep` is the right tool](https://unix.stackexchange.com/a/74190/209677). – Pablo Bianchi Apr 28 '18 at 20:49
  • Anyone: does ubuntu run apt briefly every time it boots? – John Sep 10 '18 at 19:53
  • @FaheemMitha What's the point of `grep [a]pt` ? it's the same as `grep [a]pt` in here. – Shayan Sep 04 '19 at 18:46
  • 1
    @Shayan `[a]pt` is functionally equivalent to `apt`, but `apt` will be picked up in a grep for itself, while `[a]pt` won't. It's just a little hack to filter that process out of the results. Piping `ps` through `grep` isn't necessarily the best solution generally, but hey... – mwfearnley Apr 27 '20 at 15:53
  • @mwfearnley ohh that makes so much sense, thanks very much, OP should add this to the answer. – Shayan Apr 27 '20 at 15:56
  • did ps aux | grep [a]pt two processes were running, waited some time, they automatically completed after some time – madan May 20 '21 at 09:32
  • 1
    I appreciate your answer in contrast to the others, but I'd still appreciate if you could reword the "recommendation removing lock" part to not even suggest this might be appropriate at any stage of trying to fix such issue. Please see my comment on the question and the entry on the dpkg FAQ https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_can_be_done_when_the_dpkg_lock_is_held.3F, which I'm happy to further clarify if anything is unclear or similar. – Guillem Jover Dec 25 '21 at 19:05
  • 1
    @GuillemJover Thank you for the comment and the rewrite/edit. As `dpkg`'s maintainer, you are clearly better suited to answering this question than almost anyone else. I'll let others decide on the suitability of the edit. But since it's essentially a new answer, I'm a little surprised you didn't post it as such. – Faheem Mitha Dec 26 '21 at 11:12
  • @FaheemMitha right, I considered that, and have already flagged almost any other answer that had as a reply to just remove the lock files as candidates for removal. Yours seemed like a good base on and improve, and also because it's the most correct one with the higher score. Which both help in getting further reach, as inappropriate advice to remove seems very spread, and all the answers here do not help. :/ I've also commented on the itsfoss.com article, etc. If people are more comfortable with a a new answer I could try that, but I'm not sure it would be very effective TBH. – Guillem Jover Dec 26 '21 at 17:52
  • @GuillemJover OK. I accepted the answer. Partly on faith, because I don't understand everything in the answer. But your comment is clearly compelling. Thank you for taking the time to write the answer. – Faheem Mitha Dec 26 '21 at 17:58
  • Please let me know anything that is not clear from either the edited answer or from the FAQ, so that we can improve it for other people too, as I might be too close to realize what's obvious or not. And thanks for accepting it! – Guillem Jover Dec 26 '21 at 19:29
  • 1
    @GuillemJover Given that you have gone into so much detail, it, might be helpful to include a short example transcript for the earlier part of your answer, where you mention the usage of `sudo fuser -vik -TERM /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend /var/lib/apt/lists/lock sudo dpkg --configure --pending`. It might not be obvious to many users how to use these commands. It's not immediately obvious to me. And in any case, AU is not considered to be a very hardcore technical forum. – Faheem Mitha Dec 26 '21 at 19:36
  • For what it's worth, @GuillemJover, I am a relatively competent Linux user with >20 years of using Linux under my belt, and I wouldn't know what `fuser -vik -TERM` does beyond assuming it is somehow sending `TERM` signals to running processes. Some explanation would indeed be appreciated there. – terdon Dec 26 '21 at 23:07

Remove your /var/lib/dpkg/lock file and force package reconfiguration.

sudo rm /var/lib/dpkg/lock
sudo dpkg --configure -a

It should work after this.

Bruno Pereira
  • 71,439
  • 33
  • 198
  • 221
  • these commands helped, but now when I tried to install again, got this reply : Could not get lock /var/cache/apt/archives/lock - open. I think I would have to do like previous unlocking problem, but please tell me the exact keywords for command. I'm an absolute beginner. – kern Jan 29 '12 at 11:38
  • 1
    `sudo` - execute command as root, `rm` - remove file. Maybe try `sudo rm /var/cache/apt/archives/lock` – kubahaha Sep 24 '12 at 13:56
  • 8
    This is not a good suggestion: blindly removing the lock may corrupt dpkg's state. – poolie Feb 02 '15 at 18:09
  • 8
    Why won´t it fix itself nowadays? – Marian Klühspies Nov 01 '16 at 12:19
  • 3
    This worked for me. The aws above didn't. – 1rq3fea324wre May 01 '17 at 22:53
  • 1
    Can confirm what poolie said. It has corrupted the lock state by making one of the files inparsable. It told me would would get an error when parsing `/var/lib/dpkg/updates/0006`. I removed the file in question with `rm`, reran `sudo dpkg --configure -a`, and all appears to be working as expected again. – Bacon Brad Feb 19 '18 at 21:58
  • This worked the cleanest for me. – Allen Gingrich Jan 02 '19 at 23:32
  • Only this one worked for me. It seems it's important to reconfigure packages. – Taher Jan 20 '19 at 07:13

The most likely way to hit this is:

  • boot Ubuntu
  • start a terminal
  • type sudo apt-get install whatever

and the command-line apt overlaps with update-manager automatically polling.

So if you try again in a few minutes that should fix it.

  • 9,061
  • 4
  • 37
  • 62
  • 27
    Great hint in contrast to the half-dozen replies suggesting to just remove the file ;-) I randomly ran in the issue and most likely this is it! – Alex Jan 21 '14 at 16:14
  • 2
    Safe enough, had to wait a little before `sudo apt-get install` could work. – sargas May 11 '15 at 17:56
  • Well This is not working always, yes I have used reboot many times. If it's not suitable try this http://askubuntu.com/a/315791/378845 before you remove locks – Menuka Ishan Oct 23 '16 at 07:03
  • @menuka, why not just let it finish. – poolie Dec 24 '16 at 14:38
  • @poolie Because there are other constraints which are stopping the process from finishing – Menuka Ishan Dec 24 '16 at 15:17
  • apt-get itself does not work at all. Typing your solution, error says E: could not get lock /var/lib/dpkg/lock – creator Mar 06 '18 at 00:20
  • I'm not suggesting you type anything. I'm suggesting you wait a few minutes then try again. If that doesn't fix it there's a different problem, which is possible. But most people just need to wait. – poolie Mar 07 '18 at 03:15
  • 1
    you may combine this with executing *ps aux | grep apt* to see if something is changing or monitoring with system monitor before killing anything... – Eugenio Miró Jul 19 '18 at 15:12
  • with `install whatever` you need new package or do install then remove, just change to reinstall so that can use existing package, maybe `sudo apt reinstall npm` or curl, or other small package – am05mhz May 13 '19 at 10:08

You will get this message if you forget to use sudo when executing an apt command.

Otherwise this is a sign that something else is installing or removing software and has locked the apt database while it performs the actions. The programs that can do this are:

  • The Software Center
  • The Update Manager
  • The apt link installer (I think this now goes through SC)
  • The apt-get or aptitude command line utilities.
  • The Synaptic Package Manager

IMPORTANT: only try the below as a last resort since it can crash your system. First try killing any running instance of apt or aptitude as described in Faheem's answer.

You can force the lock off by removing the file, but it's not recommended without first closing the program that's holding the lock safely, since you could cause corruption or interrupt an installation (bad). The command provided by João should close the program that holds the lock and then remove the lock but won't protect you from install interruption:

sudo fuser -cuk /var/lib/dpkg/lock; sudo rm -f /var/lib/dpkg/lock   

And the same command can be used for the apt cache lock:

sudo fuser -cuk /var/cache/apt/archives/lock; sudo rm -f /var/cache/apt/archives/lock
  • 13,606
  • 4
  • 45
  • 93
Martin Owens -doctormo-
  • 19,690
  • 4
  • 61
  • 101
  • 5
    I was updating my software when I got the error message. – raindrop Aug 16 '13 at 22:04
  • 22
    This crashed for me- – umpirsky Sep 21 '14 at 17:33
  • 5
    `sudo fuser -cuk /var/cache/apt/archives/lock` directly rebooted my computer. `apt-get` is now unlocked. – Maxime R. Dec 04 '14 at 21:47
  • 16
    This crashed my entire server. – 에이바 Jan 05 '15 at 21:28
  • 5
    Killing apt or dpkg half way through is not a great idea. – poolie Feb 02 '15 at 18:12
  • 1
    This crashed my os – Ashish Gupta Jun 20 '15 at 15:21
  • Kubuntu crashes during login after doing this. – jvriesem Nov 10 '16 at 17:20
  • If you can't log in, you can reboot in recovery mode. Choose the option to fix DPKGs. – jvriesem Nov 10 '16 at 17:35
  • You won't get `resource temporarily unavailable` if you run without it without `sudo`, you'll get `permission denied`. – poolie Mar 20 '17 at 05:36
  • The OP question says, "..is another process using it?" When you forget to `sudo` it, the message reads differently. It says, "...are you root?" – Octopus Jun 21 '17 at 03:51
  • 2
    Don't use this command, It will crash your PC, if you already tried, restart won't help you. Just shut down the PC and start. – Maduka Jayalath Feb 09 '18 at 05:58
  • WARNING: this will cause DATA LOSS, because it is instantly rebooting without any `SIGKILL`. It can damage databases and hard-drive. It will reboot as ROOT, this is also very bad, as `ecryptfs` will FAIL to decrypt home data's at next reboot!!! CAUTION GUYS!! As this answer is in top google for this query, an edit should be made. – NVRM Mar 28 '18 at 20:55
  • And this can also make your wifi card off usage at next reboot. Depending the usage, if you were using ssh, you just kicked yourself OUT. You then need physical access to reboot...... WARNING!!!! – NVRM Mar 28 '18 at 21:05
  • I didn't have any apt running and it still disabled all my services, I had to reboot. I should've just delete the lock file. – janek37 Apr 09 '18 at 08:16
  • For me, it was just because Synaptic manager window was left open. The moment I closed it, the issue on the terminal got resolved. – RBT May 10 '18 at 00:29

Only one program can hold the lock. Make sure that you are not running aptitude, synaptic or adept. Close the program and run it again it should work.You may either have synaptic open, or have another terminal window open running apt-get, or have the update manager running.Check it and see if any of those are running,if any of them is running close it and try again.

Try this command in terminal to find what is running

ps -e | grep -e apt -e adept | grep -v grep

If that doesn’t print anything, type the following in terminal to remove the lock

sudo rm /var/lib/dpkg/lock    
sudo rm /var/cache/apt/archives/lock

Now you can install any Packages.

  • 26,508
  • 16
  • 77
  • 115
  • 77,675
  • 59
  • 190
  • 232
  • 9
    Deleting the lock file is, what I would consider, a dangerous thing to do. If another process is locking for a valid reason - and you remove that lock file and force an install with what you were doing prior - you could seriously, in a negative way, affect your system. – Marco Ceppi Nov 30 '10 at 05:49
  • 6
    That's why i have given that in Note.If all the above fails the only way is to remove the lock.It wont cause any problem as long as dpkg and apt-get/aptitude processes aren't running – karthick87 Nov 30 '10 at 05:55
  • `pgrep -f 'apt|adept|dpkg'` is a lot shorter. – dhchdhd Sep 12 '17 at 21:38
  • Thx! this works. pgrep -f 'apt|adept|dpkg' and then sudo skill (number) , kill all number and then install works! – creator Mar 06 '18 at 00:22
  • @Barry that would match with the whole path+process. I think `pgrep -a 'apt|adept|dpkg'` is a better shorter equivalent. – Pablo Bianchi Mar 05 '19 at 17:01
  • @PabloBianchi `-f` has edge-cases but `-fa` if you like since pgrep without `-f` will have false negatives because the process name isn't always the same as argv[0]. pgrep really needs an option to grep the basename of argv[0] and the basename of the process name (which can be set to something else in some forms of `exec*()`). – dhchdhd Apr 02 '19 at 13:21
  • @dhchdhd Please file an issue on [`pgrep` bug tracker](https://gitlab.com/procps-ng/procps/issues). – Pablo Bianchi Apr 02 '19 at 16:24
  • Thanks, I was trying to run the command while the GUI software updater was already doing its thing. – ijuneja Mar 22 '20 at 06:08

So far the best way to get it working without breaking a possible background running installation ( as it could happen by removing the lock file), is stopping the service using apt:


# sudo apt-get upgrade
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?`


sudo systemctl stop apt-daily.timer

After upgrading the system I suggest re-enabling it, as the bug locking it could be fixed with the upgrade.

sudo systemctl start apt-daily.timer

I haven't verified this error gets fixed after upgrading. I'll add a new comment once I have that verified

  • 651
  • 5
  • 4

First of all we should check what process created the lock file using lsof:

sudo lsof /var/lib/dpkg/lock

or in another situation where /var/lib/apt/lists/lock is problematic:

sudo lsof /var/lib/apt/lists/lock

The output will be close to something like:

apt-get   12127 root   4uW  REG  252,1        0    86   /var/lib/apt/lists/lock

Then we should check what the commad is doing, we can find it out using ps, pgrep etc; the command is apt-get so I run:

pgrep apt-get -a

The -a switch lists the full command for me, in my case it's:

 pgrep -a apt-get
 12127 apt-get update

we can see that it's running update subcommand, I could run something like this too:

ps -f 12127

which produces:

root     12127 12126  0 09:39 pts/0    S+     0:00 apt-get update

In this case I would wait for some minute for resource to be freed and if after 2 or 3 minute problem still exist or the command was something that I didn't care about or was not harmful for system (like this apt-get update) I send a SIGTERM to the process:

sudo kill -15 12127

It should do the work, If it didn't I'm going to send SIGINT this time (It's like pressing CTRL+C):

sudo kill -2 12127

If it didn't work too, we should send an SIGHUP (kill -1), and finally if nothing works I simply kill the process:

sudo kill -9 12127


sudo pkill -9 apt-get

Then I remove busy resources:

sudo rm /var/lib/apt/lists/lock
  • 52,065
  • 23
  • 147
  • 173

This error may be caused by the Update Manager trying to automatically refresh the list of packages in background, usually right after your login, thus locking the directory.

In this case just wait few seconds (or more, if your last update was long ago) for it to complete or launch Update Manager to check the status.

  • 359
  • 2
  • 4
  • I had this right after installing Ubuntu 16.04. Turns out that there was a background process in the Ubuntu Software Center that was waiting for me to manually install some updates. – jvriesem May 12 '16 at 21:16
  • Ditto after a fresh install of 16.04. It too much longer than "a few seconds" in my case (I had time to read this whole Q&A page!) but after refreshing `ps` a few times I could see `dpkg` was updating a whole load of stuff and I waited patiently for it all to finish. I then ran **Software Updater** until everything was up-to-date before trying to install anything new. – Charlie Joynt Mar 02 '17 at 21:51

Don't be so fast to remove something, it may totally damage your system; rather wait until the currently installing or uninstalling program finishes its task and after that you will get access. If you think that there is nothing currently installing or uninstalling, then just reboot your system with the command sudo reboot.

  • 34,549
  • 13
  • 96
  • 149
  • 331
  • 3
  • 4
  • 1
    This looks like a comment rather than an answer. Could you move this instead as a comment to the answer it was responding to? – jvriesem May 12 '16 at 21:15
  • 4
    @jvriesem I think this is a very important answer, because the point he's making is what is missing from many other answers! – Volker Siegel Jul 02 '16 at 10:31
  • @jvriesem This is usually the correct answer. I run into this problem quite often with my linux containers when I don't use them a long time. Just wait. Yes it may be a while. But let it do its job before going in and disrupting things. – earth2jason Mar 23 '19 at 13:57
  • This should be the first thing to try. This answer most of the time fixes the problem. I had it maybe 4-5 times yet, and a reboot always solved it. – Jan Jul 02 '19 at 06:47

If you have security updates set to auto-install this will happen frequently. I literally wait 30 seconds and it fixes the issue. Just throwing this out there in case anyone else encounters this issue.

  • 303
  • 4
  • 7
  • 1
    Depending on how long the distro has been booted, it could be as long as a half hour. But it's probably ideal to let your distro finish its job before disrupting things. – earth2jason Mar 23 '19 at 13:58

In my case, I had to wait for several minutes for the lock to be released (looks like apt used to hold it). This all happened right after system boot.

  • 616
  • 1
  • 7
  • 13
Pavel Vlasov
  • 313
  • 1
  • 4
  • 8

I have had this issue numerous times. For me, it was almost always caused by apt-get or some GUI that called it getting hung for some reason. I had to kill it which left various locks in place.

The other answers bring up very good points about making sure no updates are currently running before doing anything drastic like removing lock files. However, once you are sure that's not the case, the following usually works for me. I got it by reading many answers to questions like this one.

While most or all of this is presented in the other answers, this distills the fix down to a few commands.

sudo fuser -vki /var/lib/dpkg/lock
sudo fuser -vki /var/cache/apt/archives/lock
sudo fuser -vki /var/cache/debconf/config.dat
sudo dpkg --configure -a

Use for unlocking the package system after an update of some kind crashed or terminated without finishing in some other way. These commands should be run in the order presented.

  • 1,789
  • 14
  • 27

Check the Launcher to see if Software Updater is running. If so maximize it and have a look at what it is doing. If it is still checking, then wait for it to complete. When it completes it might tell you the software is up-to-date so close the app. If it says there are updates available, either do the update or click "remind me later". After this this app closes you can go back to using apt-get or apt.

If Software Updater is not running, just use the Dash to invoke it and the wait for completion and then decide if you want to update or click "remind me later". After this this app closes you can go back to using apt-get or apt.

  • 9,191
  • 27
  • 70
  • 108
sudo killall -9 apt && sudo killall -9 dpkg

Use at your own risk

  • Perhaps not that bad to apply killall? At least this question's duplicate https://askubuntu.com/questions/1109982/e-could-not-get-lock-var-lib-dpkg-lock-frontend-open-11-resource-temporari has an answer which recommends the same. In my case, its output was `apt: no process found`, and afterwards, a `sudo apt-get ...` command reacted differently, saying `E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.` which is part of the highest voted answers. – questionto42standswithUkraine Dec 29 '20 at 13:38

I don't see this answer anywhere above but on Ubuntu 16.04, I encountered this problem as well. The cause was the time on my computer was set into the future. (This is because I'm on a Windows+Ubuntu dual boot system and I guess I have messed up local time vs UTC time.)

One odd thing was that the locked file's date and time was the exact date and time that I ran the program.

I then used "fuser" as described in earlier posts and apt worked, but I was getting complaints about needing to run dpkg -a -reconfigure. When I did that, I got errors like:

newline in field name #padding

in files like '/var/lib/dpkg/updates/0003'.

All of this was very strange as I've never seen it before. So, I thought these were symptoms and changed my data and time manually. I knew there was a problem with the date/time when I logged in, but was ignoring it. (Previously, it was setting it automatically via the Internet and NTP).

Then, all of the above problems were fixed... Hopefully, this helps someone else! The most notable symptom is perhaps the date/time of the lock file being the exact date/time that you are trying to run the command.

  • 1,869
  • 16
  • 25

In my case, X crashed while apt-get was still removing old kernels. I used the System Monitor to confirm it was still running and not stuck. Everything was fine once the process finished.

  • 13,606
  • 4
  • 45
  • 93

In my case I was getting the same message by not realizing I had switched to root user and was trying sudo apt-get. Once I realized this I just ran apt-get, and it worked. Silly, but it might still explain the error for some.

  • 157
  • 5
  • 2
    That's not the cause of the issue, since you *can* run `sudo` as root (and even if you couldn't, it wouldn't produce this error message). More likely what happened was that the other process finished while you were writing the next command. – wjandrea Oct 24 '17 at 05:06
  • Sometimes it does produce that same error message. – karel Dec 23 '17 at 00:31

in my case, after:

  1. Open Firefox.
  2. Open terminal

I typed

sudo apt update
sudp apt upgrade
then I get that problems

E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
I fixed that, running the command that was showed me after run sudo apt update
apt list --upgradable

This command will show you a list of programs in my case only Firefox, I closed Firefox, then could ran the command again without problems.

sudo apt upgrade
  • 1,754
  • 2
  • 11
  • 19

For people who are interested in proactively preventing this bug in their scripts, I found that the -q flag on apt upgrade -yq was causing this issue for me. During the upgrade process I guess it would occasionally give me warnings (something along the lines of updating the desktop, would I like to continue), and if these warnings were suppressed, then I guess that causes apt to not unlock the files it was protecting and it got stuck.

Admittedly, I had trouble reproducing this error 100% of the time, but eliminating that -q option completely fixed the issue for me.

Tyrel Kostyk
  • 221
  • 2
  • 3

Like most everyone else I waited for the lock to be removed. After 30 minutes I gave up and hard booted to a different distribution. From there I used the internet for some research which landed me here.

It turns out unattended-upgrades.service is running. I found that be rebooting into the broken system and running:

sudo systemctl disable apt-daily.service
sudo systemctl disable unattended-upgrades.service
sudo systemctl disable apt-daily-upgrade.service
sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl disable apt-daily.timer
sudo shutdown -r # Note it will take a couple minutes to reboot

allowed me to get the broken system working again for:

sudo apt update
sudo apt upgrade
sudo apt install -f

However it didn't fix the kept-back packages and impossible situation reported by apt in the first place. It would appear this was causing apt to lock up at boot in the first place.

  • 95,212
  • 32
  • 218
  • 388
  • Find unattended-upgrade defaults in APT conf e.g. `sudo nano /etc/apt/apt.conf.d/50unat- tended-upgrades` – TimD Oct 23 '20 at 13:26
  • Removing the below files, solved my issue. sudo rm /var/lib/dpkg/lock sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/lib/apt/lists/lock sudo rm /var/cache/apt/archives/lock Please refer https://phoenixnap.com/kb/fix-could-not-get-lock-error-ubuntu – Malar Kandasamy Dec 09 '20 at 16:39

I have tried the top upvoted answers on this page and they always worked for me without exception, however I discovered an easier way to solve this problem. First some theory. What happens before a user gets this error message?

E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?  

/var/lib/dpkg/lock is locked so the terminal temporarily can't use it, but what process is it locked by? This depends on the circumstances. If you have booted the computer a few minutes ago it is probably locked by the Software app. Try closing the terminal and launching the Software app. If the Software app is indeed locking /var/lib/dpkg/lock it will show a screen that says Software catalog is being downloaded when you open it.

enter image description here

After the Software app finishes updating it will show a popup notification message, and another Software Updater window may also appear as show below. Otherwise the Software app will remove its own lock without the user needing to run any commands in the terminal.

enter image description here

After it has finished updating the software the Software Updater will remove its own lock without the user needing to run any commands in the terminal.

Another case where this answer is useful is in a VM when booting an Ubuntu guest OS that has been inactive for a while. Normally the Ubuntu guest OS starts to update almost immediately. The updating process frequently locks out commands that require installing, removing or updating software until it finishes. Open the Software app, let it finish running and install whatever updates that you want it to install. The Software app will remove its own lock when it finishes.

  • 102,924
  • 86
  • 253
  • 284

Just reboot and it will auto fix the problem. This is your installation interrupted accidently.

  • 121
  • 4

Adding this only in the hope that it might be connected, I have not tested this solution. If deleting the lock files does not help, and if it is not even recommended according to the accepted answer, it might help how the similar problem dpkg: error: dpkg status database is locked by another process could be solved using the recovery mode with sudo dpkg --configure -a in the root shell prompt.

Copy from there:

I had removed the lock files, and there was no PID running, yet, whenever I executed sudo dpkg --configure -a, the shell was stuck at one of the previously locked "apt" tasks that I had force-closed by closing the terminal in the end. I also killed the apt processes using sudo killall apt apt-get. The stuck apt task in my case was "Setting up docker-ce (5:20.10.1~3-0~ubuntu-bionic)".

Solution in my case:

  • Boot in recovery mode.
  • In the recovery menu, choose "root" in order to "Drop to root shell prompt".
  • Press Enter.
  • Type sudo dpkg --configure -a.
  • Go on with what you were about to do, it should work now, and / or just reboot.

Please see screenshots and detailed explanation (e.g. how to get the recovery mode at start) at the answer of docker ps stuck … docker install also just hangs.


My solution was:

sudo apt update
sudo apt upgrade

Runtime environment:
   Operation System: Ubuntu 18.04
   Computer:Dell Precision 5510

Cloud Cho
  • 445
  • 6
  • 10