I’ve updated this. The new stuff is at the bottom.
I was updating my Debian machine last night before I went to sleep. I woke up this morning to the login screen. No big deal I logged back in and tried to verify that everything went okay.apt-get update resulted in /var/cache/debconf/config.dat is locked by another process.
Of course I knew immediately what to do from this descriptive error message…consult google.
I knew, subconsciously, that apt had screwed the pooch somewhere during the night and borked Dpkg but ps aux didn’t reveal anything immediately responsible, so I typed the error message directly into google to see what might turn up.
Apparently, quite a few people have a a similar problem lately with Sarge but I couldn’t quite find an answer. In frustration, I rebooted the machine hoping to kill whatever process was running in memory that had Dpkg locked and it worked.
I still haven’t determined which process was responsible for locking config.dat but a simple reboot will clear the problem.
Just to sum up, if you’re having this problem, reboot the machine, that will fix it.
Thank you, that is all.
When I wrote this little blurb back in February, I’d just reinstalled my machine using the then new Sarge netinst-aller and had issued the ever-loved and popular `
apt-get update;apt-get upgrade‘ before tucking in for the night. I’ve issed that string of commands about a million times and I’ve never had to think twice about it, nor did I that night.
Now, before I go any further, let me say that this was three Sarge netinst-images ago and the machine in question I was installing to had been having problems for about six months. This same machine completely died on me about three weeks ago, which is why the site hasn’t been updated and also why the new bashblogger hasn’t been released yet. I’ve only been back up and running for a little while and everything’s solidifed over the last week.
Let me also further clarify that doing a `ps aux‘ didn’t reveal any dpkg processes nor any perl processes. Since I was on a fresh install and since I was using a beta installer, I just rebooted the machine and the problem cleared up. The previous information is still correct, if you reboot your machine, the problem will go away.
However (comma) as an email I received tonight from a good person who will go unnamed (hi, Juho), pointed out, you do not have to reboot your machine to fix the problem. The “correct” way to kill of a problem process that won’t show up for `ps aux‘ is to run `lsof‘ and look for any processes related to dpkg there.
`lsof‘ will spew out about 15 screens worth of information about everything going on, on your system. Pipe the output to your favorite pager (I prefer less, some like more) `lsof | less‘ and scour through all of the information until you find the dpkg-related process and kill it off. The first column will be the command name, the second column is the process id, which you’ll need to kill the process off.
After you’ve determined what’s hung up and won’t have the good graces to die, issue `kill -9 <process id>‘ and that will take care of the problem without the need to reboot.
I decided to reboot my machine because it was a fresh install and because I didn’t have servers up and running yet and blah, blah, blah. You may be in a situation where you can’t really afford to reboot and it’s nice to know the “right” way to do things.
Hope I cleared all that up.
Update | January 3, 2006
David Ward sent in another method to fix the dpkg.dat problem:
user@machine:~$ sudo fuser /var/cache/debconf/config.dat /var/cache/debconf/config.dat: 26509 user@machine:~$ ps ax | grep 26509 26509 pts/2 S+ 0:00 /usr/bin/perl -w /usr/sbin/dpkg-preconfigure --apt 26606 pts/1 R+ 0:00 grep 26509 user@machine:~$ kill 26509
Hope that helps somebody.
Posted by Philip McClure in Linux on February 03, 2005