Technically, the error is thrown by the system in multiple scenarios, and one should really take care about how he/she goes aout solving this problem. In this article we will discuss all these aspects related to this error and how you can safely get rid of it.
Unable to lock (/var/lib/dpkg/) – diagnosing the problem
Whenever you encounter this error, the first step should be to read the error description carefully. It usually contains some crucial and time-saving hints. As an example, the following screenshots show the “apt-get install” command throwing similar looking errors.
However, if you take a closer look, you’ll observe that the text within brackets in the first line and the text after the comma in the second line are different in both scenarios making it clear that the error in the first scenario has something to do with user permissions, while in the second scenario it is related to the lock file being temporarily unavailable. If you’re facing a permission-related error (as shown in the first image above), it’s most likely because the user running the “apt-get” or “apt” command doesn’t have sufficient privileges and the command was run without sudo. Once the command is run with root privileges, the error will go away. However, if it’s a lock-related error, then it requires further investigation.
What is /var/lib/dpkg/?
“/var/lib/dpkg/” can be thought of as the working directory for package manger “dpkg,” which in turn is actually the engine behind “apt-get” (as well as “apt” and “aptitude” tools). Whenever you use these tools to install or remove software, they lock the package database (by creating a “lock” file) before performing the actual operation, something which is actually done by getting the lock for the “/var/lib/dpkg/” directory. This step helps avoid data corruption or interruption of an ongoing operation that is being performed by some other process. Assuming you’ve understood the above explained concept, let’s now discuss the investigation steps.
Step 1: See if there’s any other process holding the lock
This should now seem quite logical, right? And to do this, you can use the help of the good old ps command and pipe its output to the grep command so that you spend less time looking for what you want. For example, here’s a command that lets you find if any “apt,” “apt-get,” or “aptitude” process is already running:
Step 2: Wait for a while and then take action
If indeed there’s a command that has already acquired the lock, you should ideally wait for it to complete and release the lock. However, if the command is taking more than the expected time and you are sure that it’s stuck somewhere, you can go ahead and kill it using the available kill or killall commands (more info on them here). This should solve the problem you’re facing. One thing worth mentioning here is that killing a “dpkg” process directly is never recommended – it may corrupt the package database. I am stressing this point because now you know that tools like “apt” and “apt-get” invoke “dpkg” internally, so it’s quite possible that you might think of killing the “dpkg” process if you spot it in the “ps” command output. Killing processes initiated by running apt, apt-get or aptitude commands generally much safer.
Step 3: When the “ps” command output doesn’t help
Keep in mind that aside from command line tools like apt and apt-get, some GUI-based applications like the Software Center or the Update Manager also acquire this lock. Note: if you are getting the lock-related error just after you’ve booted into Ubuntu, it’s quite possible that your operation is overlapping with the automatic polling initiated by the update-manager. Waiting a bit should solve the problem in this case. Coming back to the GUI-based applications we were talking about, another useful and time-saving option is to use the fuser command. With “fuser” you only need to know the file being accessed (“/var/lib/dpkg/lock” in our case), and you can kill the process accessing that file even if you don’t know which process it is. For example: Keep in mind that the fuser command will not release the lock acquired by the process you just killed, so you’ll have to do this manually: Note: to “release the lock” simply means deleting the “lock” file so that other processes can “acquire the lock” by recreating it. You may also need to run the following two commands: Important tip: never ever delete lock files as a first step – this should only be your last resort.
Conclusion
In general, it’s always good to understand the reason behind the problem before going ahead and solving it. Blindly trying solutions to solve a problem will never help you – you might succeed in some cases, but more often than not you will find yourself in an even bigger mess, especially if the OS is Linux. Have you ever faced the error we discussed here? How did you sort it out? Leave your answer in the comments.
