Here are multiple solutions to resolve this issue, but if the first 2 don’t work out, jump to the 5th answer.
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.
Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?
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
.
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
Answer #3:
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
Note:
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.
Answer #4:
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.
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.
Answer #5:
This should be used as a 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.
Answer #6:
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.
Answer #7:
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:
Error:
# 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?`
Solution:
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.
Answer #8:
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:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
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:
UID PID PPID C STIME TTY STAT TIME CMD
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
or
sudo pkill -9 apt-get
Then I remove busy resources:
sudo rm /var/lib/apt/lists/lock
Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?
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.
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
.
Answer #10:
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.
Answer #11:
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.
Answer #12:
In my case, after:
- Open Firefox.
- 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
Hope you learned something from this post.
Follow Programming Articles for more!