Installation Error, "Unable to lock the administration directory" [duplicate]
Solution 1:
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.
Solution 2:
(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.