Keith wrote:
>
> Hi all,
>
> Recently (I think, starting a couple of days ago) when I boot up, the
> update applet runs, tells me that there are updates to be installed, and
> then when I tell it to go ahead it fails, saying that the database is
> already locked. Below is the relevant section of /var/log/syslog. It
> would seem that the error near the top is the culprit, but is there a
> workaround, and why is it happening?
================================================== ==
When database is locked I do the following :

[root@localhost frank]# rm -f "/var/lib/urpmi/.LOCK"
[root@localhost frank]# rm -f "/var/lib/urpmi/.RPMLOCK"

After that updates get installed .

Frank

Highland Ham wrote:
> Keith wrote:
>>
>> Recently (I think, starting a couple of days ago) when I boot up, the
>> update applet runs, tells me that there are updates to be installed,
>> and then when I tell it to go ahead it fails, saying that the database
>> is already locked. Below is the relevant section of /var/log/syslog.
>> It would seem that the error near the top is the culprit, but is there
>> a workaround, and why is it happening?
> ================================================== ==
> When database is locked I do the following :
>
> [root@localhost frank]# rm -f "/var/lib/urpmi/.LOCK"
> [root@localhost frank]# rm -f "/var/lib/urpmi/.RPMLOCK"

Good workaround - thanks. Does anyone have any idea why this is
happening in the first place?

Keith wrote:

> Highland Ham wrote:
>> Keith wrote:
>>>
>>> Recently (I think, starting a couple of days ago) when I boot up, the
>>> update applet runs, tells me that there are updates to be installed,
>>> and then when I tell it to go ahead it fails, saying that the database
>>> is already locked. Below is the relevant section of /var/log/syslog.
>>> It would seem that the error near the top is the culprit, but is there
>>> a workaround, and why is it happening?
>> ================================================== ==
>> When database is locked I do the following :
>>
>> [root@localhost frank]# rm -f "/var/lib/urpmi/.LOCK"
>> [root@localhost frank]# rm -f "/var/lib/urpmi/.RPMLOCK"
>
> Good workaround - thanks. Does anyone have any idea why this is
> happening in the first place?

I have the same problem, i remove the locks and it works but within a day i
have the same problem again

Keith wrote:

>Highland Ham wrote:
>> Keith wrote:
>>>
>>> Recently (I think, starting a couple of days ago) when I boot up, the
>>> update applet runs, tells me that there are updates to be installed,
>>> and then when I tell it to go ahead it fails, saying that the database
>>> is already locked. ...

>> When database is locked I do the following :
>>
>> [root@localhost frank]# rm -f "/var/lib/urpmi/.LOCK"
>> [root@localhost frank]# rm -f "/var/lib/urpmi/.RPMLOCK"
>
>Good workaround - thanks. Does anyone have any idea why this is
>happening in the first place?

My suspicion is that update sometimes tries to run on logout. I think
that this hangs the logout for about 20 seconds, then the logout process
forcibly terminates the update leaving the lock files in place.

--
Dave Farrance

On Sat, 16 Aug 2008 06:20:02 -0400, Keith wrote:

> Recently (I think, starting a couple of days ago) when I boot up, the
> update applet runs, tells me that there are updates to be installed, and
> then when I tell it to go ahead it fails, saying that the database is
> already locked. Below is the relevant section of /var/log/syslog. It
> would seem that the error near the top is the culprit, but is there a
> workaround, and why is it happening?
> Aug 16 09:58:40 localhost mdkapplet[4923]: running: urpmi.update > arguments>
> Aug 16 10:08:40 localhost mdkapplet[4923]: ERROR: killing runaway
> process (process=urpmi.update, pid=5459, args=--update, error=ALARM at
> /usr/lib/libDrakX/run_program.pm line 81. )

You could try editing the above file to increase the timeout. I have disabled
mdkapplet (right click on the icon, to disable/stop it), and only run the
check for updates, when I want to, using the command line with
urpmi --auto-update --keep --resume

If you later decide you want mdkapplet back, edit ~/.MdkOnline/mdkonline, and
change the AUTOSTART=FALSE to TRUE, or run "mdkapplet -f".

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)