Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?

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.