LinuxQuestions.org - package management

Quote:

Originally Posted by ramayana (Post 3156112)

<fice.org-core' 'openoffice.org-kde' ;echo RESULT=$?
E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
RESULT=100

The lock file errors seem to point that one package manager (apt) process is already running, or it was running and exited uncleanly so that the lockfile was left behind. The idea behind a lockfile is that once you start the package manager, it creates a file -- empty file usually -- called "a lockfile" to some directory (for example /var/lib/dpkg/ in this case, a file that is simply called 'lock'). Then if you try to run another instance of the package manager before the other one is closed, it finds the lockfile and refuses to start, because running two package managers at the same time could cause serious trouble -- for example the two programs could be installing or removing the same package the same time. So the lockfile is there to point out that an instance of the package manager is already running, and when that process exits, the lockfile is removed; though if the process for some reason exits so that it doesn't remove the lockfile (for example you kill it without letting it remove the file, or the program crashes), the file remains even though there is no package manager running, and this means no new package manager process wants to start.

Solution is simple: first make sure there are no package manager processes running (dpkg, apt-get, adept, synaptic, ...) and if the file still is there, simply remove it. You should not remove it if there is a package manager process running, because then another process could accidentally start and interfere with the other one, but if there are no processes, the file is "not used" by anybody. So (you need to be root to do these things, killing processes not owned by you and all:

Code:

su -

This will make you become the root user, or superuser. Type password (of root) when asked, or use 'sudo' with the commands below instead.

Code:

ps -e |grep apt

ps -e |grep dpkg

ps -e |grep adept

The above commands don't show anything (i.e. you just get a new command line) if there are no processes named apt, dpkg or adept (just three examples) running; if there are, you'll get a line per process that shows some information. For example if there was 'dpkg' running, you could kill it using

Code:

killall -q dpkg

Or by using 'kill' with the pid (process id) number, but killall does the job too - kills all processes called dpkg. Now let's assume you don't find any package manager processes running anywhere anymore. If

Code:

ls /var/lib/dpkg/lock

gives output, the file is still there. Remove it:

Code:

rm /var/lib/dpkg/lock

Now retry running adept, for example, and see if it works.

With Adept I've found this sometimes happens; the application crashes, leaving an unneeded lock file behind. Installing Synaptic (which is a front-end to the package manager just like Adept, but with a GTK interface rather than QT, so it might not sit as well into KDE desktop than Adept does - but on the other hand, Synaptic is in my opinion somewhat "more clear" in terms of usage than Adept) won't get you past the lockfile problem, but if it's Adept that causes the lockfile-leftovers, then you might get less headache using Synaptic. If you are fine with it's outlooks and the interface, go ahead, it won't harm anyone :)

Hope it helps.