How can I solve "Be aware that removing the lock file is not a solution and may break your system"? [duplicate]

I did:

sudo apt-get update

I got this:

Reading package lists... Done
E: Could not get lock /var/lib/apt/lists/lock. It is held by process 1131 (packagekitd)

N: Be aware that removing the lock file is not a solution and may break your system.

E: Unable to lock directory /var/lib/apt/lists/

I used to just remove the lock file, but I've never seen that note before (did it break my system?)??

What do I do?

Solution 1:

Only if you are sure that there is no ongoing software installation or updates, restart your computer, and the lock will be removed. Beware that restarting your computer during a running update can break your system.

If a restart does not help: Try to restart the packagekit service. The terminal command to restart packagekit is:

sudo service packagekit restart

More details - This means dpkg (or apt) was either interrupted, or it is still running in the background.

If you are either updating or installing some software, wait until that is finished. As mentioned in the comments, the use of packagekitd suggests that a GUI frontend is indeed running an update or checking for updates.

Removing lockfiles manually is unsafe, and the other answers explain how to safely do that. Restarting the computer automatically removes old lockfiles, and it is one of the easiest ways to get rid of the issue.

Solution 2:

The lock file was created by process 1131 (packagekitd). It was created so that that process could make changes to the package system without worrying about other programs doing other changes at the same time.

If you remove the lock file, you make it possible for another process, such as apt-get, to make changes simultaneously with packagekitd. Since there was no lock file, apt-get will also assume it is the only process making changes.

The result can be that some of the changes made by one process can be overwritten by the other. The end result will be some random mixture of the two change sets, which might result in a broken system.

It is possible to write programs so that they can work at the same time without stepping on each others toes, but it is difficult and can give some really obscure bugs. The authors of this package system decided it was better to just make a global lock file. This is simple and robust, but not very friendly to multi-taskers.

Now, all this assumes that packagekitd is still running and doing things. If this process has in fact crashed without removing the lock file, the situation is different.

This might have left the system in a "halfway" state, but the package system is designed to detect and recover from that. (This is easier)

Rebooting is a very heavy-handed way of making sure that packagekitd is not running anymore. During boot old lock files will be deleted since they can no longer be relevant.

If you are 100% sure the process has crashed, you can remove the lock file without rebooting. Use psto check if process 1131 is still around.

If you are fairly certain the process is stuck somehow and will never end, you can kill it safely. If you think it might be working as intended but just at an inconvenient time it is best to just wait until it is finished. If this is not possible, you can still kill it safely.

Solution 3:

Never just remove a lock unless you are sure it is stale. Some locks are tied to running processes and will disappear when the process exits. Other kinds of locks are maintained manually and can get left behind (go stale) if the process crashes. I believe this particular lock is in the former category and so it shouldn't be able to go stale. If it's locked, there is something actively holding it and it shouldn't just be removed.

If you look at the error carefully, you will see which process it is, packagekitd, and it's PID is 1131. You can see this pid by running ps u --pid 1131. The PackageKit program is used for helping with system updates and installing software when needed and so is very likely the culprit here. The best option is to either wait for it to finish with it's task, or try to kill it gently with kill 1131 if impatient. That uses a SIGTERM signal which politely asks it to terminate and it will have a chance to do appropriate clean-up. Don't try to kill it with -9 or SIGKILL unless you truly believe it has hung and crashed.