This is also true if you reboot? Maybe some old apt thread is locking the file, you need to find out which and kill it or just rebooting will do it.
–
Bruno PereiraJan 29 '12 at 11:19

3

This procedure almost always fixes this problem, and when it doesn't, its output (the text from the Terminal) is sometimes useful. If you decide to do it, you can add this text to your question.
–
Eliah KaganJun 6 '12 at 9:10

1

I would suggest one more thing that you may note when faced with this issue. Do check if your disk drives are mounted. If they are not, you may not be able to acquire the lock as the package installer will not be able to access the filesystem. Hope this helps. :)
–
HariApr 6 '13 at 12:23

3

You can use sudo lsof /var/lib/dpkg/lock to find the process that owns the lock file (if empty, assume the lock is left over from a previous boot and can be sudo rmd), then consider doing a sudo kill -9 <PID> (get <PID> from lsof output.
–
waltinatorMar 17 '14 at 22:01

1

This can be a sign that something else is installing or removing software and has locked the apt database while it performs the actions.
–
ForeeverFeb 3 at 4:32

I see pretty much all the answers recommend deleting the lock. I don't recommend doing that as a first measure; maybe if there is no alternative. The lock is placed when an apt process is running, and is removed when the process completes. If there is a lock with no apparent process running, this may mean the process got stuck for some reason.

If you try

ps aux | grep apt

that will catch processes containing the word apt, at least. If you see an apt-get process or an aptitude process that looks stuck, you can try

kill processnumber

and if that doesn't work try

kill -9 processnumber

This should kill the process and may remove the lock. Killing an apt or aptitude process is harmless unless it is actually in the middle of package installation. In any case, if the process got stuck, you probably don't have a choice but to kill it.

Also, I would kill dpkg. This worked for me, as it was trying to finish something it stared before the machine was stopped previously, and couldn't figure it out on his own.
–
moryniczSep 14 '13 at 18:46

6

@Link I don't think killing dpkg is a good idea, because usually dpkg is manipulating the package database directly, and this could cause corruption.
–
Faheem MithaSep 14 '13 at 20:17

There was no need to kill dpkg. After killing the stuck apt-get process, dpkg went away automatically.
–
friederbluemleOct 3 '14 at 4:16

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.

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:

these commands helped, but now when I tried to install again, got this reply : Could not get lock /var/cache/apt/archives/lock - open. I think I would have to do like previous unlocking problem, but please tell me the exact keywords for command. I'm an absolute beginner.
–
kernJan 29 '12 at 11:38

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

Deleting the lock file is, what I would consider, a dangerous thing to do. If another process is locking for a valid reason - and you remove that lock file and force an install with what you were doing prior - you could seriously, in a negative way, affect your system.
–
Marco Ceppi♦Nov 30 '10 at 5:49

3

That's why i have given that in Note.If all the above fails the only way is to remove the lock.It wont cause any problem as long as dpkg and apt-get/aptitude processes aren't running
–
karthick87Nov 30 '10 at 5:55

This will happen if you have 'Update Manager' running in parallel for any update check or install as install process places Lock. If you're facing the same error without 'Update Manager' running you have to remove it from /var/lib/dgkg/lock, which definitely you can't do it manually

dont b so fast to remove something, it may totally damage your system rather wait until the current installing or uninstalling program finishes its task and after that you will get access for the lock. if you think that there is nothing installing or uninstalling currently, then just reboot your system with the command sudo reboot

The process "fuser" will access the communication with the graphics card, and possibly eliminate it.
If you plan to execute this command, first type Ctrl+Alt+F2 and execute it in a different tty session, so your graphics is not changed while it is used by your Xorg session.

I'm afraid I prefer @João Pinto's solution. Deleting a lock file without checking whether any processes are using is a bad idea, so I'm downvoting this.
–
FlimmDec 4 '12 at 14:03

5

This is indeed a very bad idea. These lockfiles should never be deleted. apt/dpkg don't leave them locked when the process exits, so if something says they are locked, they damn well are.
–
Dennis KaarsemakerApr 6 '13 at 14:30