11:34 a.m.
I installed fedora core 2 test 2 this morning, and some tool locked up
while using RPM. Now RPM has died - I type any command in and it just
sits there with no output.
I seem to remembering having to clear a cache or lock file, or maybe
even rebuilding the RPM database.
Any suggestsions?
Martin Alderson,
IntechHosting
Email: martin(a)intechhosting.co.uk
Web: http://www.intechhosting.co.uk
11:50 a.m.
On Sat, 3 Apr 2004, Martin Alderson wrote:
I installed fedora core 2 test 2 this morning, and some tool locked
up
while using RPM. Now RPM has died - I type any command in and it just
sits there with no output.
I seem to remembering having to clear a cache or lock file, or maybe
even rebuilding the RPM database.
Any suggestsions?
First off, get the output from the back trace. To do this find rpm's
pid, and then run:
gdb -p $pid
bt # This is in gdb
Send that output to the list. There are two case of lockups that I know
of. One, the program using librpm was kill with a -9 or it exited before
closing the rpmdb. This one is pretty common, and the back trace will
show if this is the case. This lockup is not a bug in rpm, and is fixed
by removing the files:
/var/lib/rpm/__db*
The second one, I have only seen the CVS head, but it coudl be elsewhere,
is when rpm hangs while waiting for a scriptlet to exit. This one is
very intermittent (almost rare, but if you do enough transactions your
guaranteed to see it depending on your hardware). Again, if I see
the back trace I can almost certainly discern that that is what is going
on. I wrote a bugzilla report on this, and a reasonable attempt was made
to fix it, but I am still seeing on my test mule.
Cheers...james
Martin Alderson,
IntechHosting
Email: martin(a)intechhosting.co.uk
Web: http://www.intechhosting.co.uk
11:55 a.m.
On Sat, Apr 03, 2004 at 12:50:48PM -0500, James Olin Oden wrote:
On Sat, 3 Apr 2004, Martin Alderson wrote:
> I installed fedora core 2 test 2 this morning, and some tool locked up
> while using RPM. Now RPM has died - I type any command in and it just
> sits there with no output.
>
> I seem to remembering having to clear a cache or lock file, or maybe
> even rebuilding the RPM database.
>
> Any suggestsions?
>
First off, get the output from the back trace. To do this find rpm's
pid, and then run:
gdb -p $pid
bt # This is in gdb
Send that output to the list. There are two case of lockups that I know
of. One, the program using librpm was kill with a -9 or it exited before
closing the rpmdb. This one is pretty common, and the back trace will
show if this is the case. This lockup is not a bug in rpm, and is fixed
by removing the files:
/var/lib/rpm/__db*
Also the new rpm transaction lock:
/var/lock/rpm/transaction may need to be removed.
The second one, I have only seen the CVS head, but it coudl be
elsewhere,
is when rpm hangs while waiting for a scriptlet to exit. This one is
4.3 is pretty close to HEAD I guess.
Paul
12:08 p.m.
On Saturday 03 April 2004 12:50, James Olin Oden wrote:
On Sat, 3 Apr 2004, Martin Alderson wrote:
> I installed fedora core 2 test 2 this morning, and some tool locked up
> while using RPM. Now RPM has died - I type any command in and it just
> sits there with no output.
>
> I seem to remembering having to clear a cache or lock file, or maybe
> even rebuilding the RPM database.
>
> Any suggestsions?
First off, get the output from the back trace. To do this find rpm's
pid, and then run:
gdb -p $pid
bt # This is in gdb
Send that output to the list.
No! Please do not send to the list. File a bugzilla report of your problem
and add the backtrace there.
However, as described below, you may be able to easily fix you problem.
There are two case of lockups that I know
of. One, the program using librpm was kill with a -9 or it exited before
closing the rpmdb. This one is pretty common, and the back trace will
show if this is the case. This lockup is not a bug in rpm, and is fixed
by removing the files:
/var/lib/rpm/__db*
The second one, I have only seen the CVS head, but it coudl be elsewhere,
is when rpm hangs while waiting for a scriptlet to exit. This one is
very intermittent (almost rare, but if you do enough transactions your
guaranteed to see it depending on your hardware). Again, if I see
the back trace I can almost certainly discern that that is what is going
on. I wrote a bugzilla report on this, and a reasonable attempt was made
to fix it, but I am still seeing on my test mule.
--
Gene
8:12 p.m.
On Sat, 3 Apr 2004, Gene C. wrote:
On Saturday 03 April 2004 12:50, James Olin Oden wrote:
> On Sat, 3 Apr 2004, Martin Alderson wrote:
> > I installed fedora core 2 test 2 this morning, and some tool locked up
> > while using RPM. Now RPM has died - I type any command in and it just
> > sits there with no output.
> >
> > I seem to remembering having to clear a cache or lock file, or maybe
> > even rebuilding the RPM database.
> >
> > Any suggestsions?
>
> First off, get the output from the back trace. To do this find rpm's
> pid, and then run:
>
> gdb -p $pid
> bt # This is in gdb
>
> Send that output to the list.
No! Please do not send to the list. File a bugzilla report of your problem
and add the backtrace there.
Let me rephrase this. I am hunting this bug down with Jeff Johnson
(though, he has figured out much more than me) and I want to see the
back trace. If its the traditional rpmdb locks no bug report is required
nor wanted, cause it will probably be a nofix. If it is this new lockup
with scriptlets, then I very much care, and there is already a bugzilla
report that may need to be re-opened. So, if you don't want to see this
sort of stuff on the testers list fine, but it would be very much
acceptable to send it to rpm-list(a)redhat.com. The bug I am looking at
is bugzilla #117620. What I wanted to know in particular (and I can tell
from the backtrace, is is this the same bug, rather than have him right
a new bug that would have to be duped.
However, as described below, you may be able to easily fix you
problem.
If it is the bug I am on the trail of then the answer is not as simple as
that. Basically, if you kill rpm with a -9 and then remove the __db*
files (only because you just had to kill rpm with a -9), then the next
rpm transaction is not likely to lockup. The problem has not gone away,
though, its just that its a tricky little race condition as near as I can
tell such that the problem is still there waiting to rear its head when
you really don't want it to.
Cheers...james
1:15 p.m.
After a reboot it seems to have fixed itself. Hopefully it was just a
one off bug of some sort and won't occur again.
Also, is it common for up2date to just lock up? It seems to for me very
much so I just use the up2date applet thing and launch synaptic to
update. What are other people's views on this
Regards,
Martin Alderson,
IntechHosting
Email: martin(a)intechhosting.co.uk
Web: http://www.intechhosting.co.uk
8:30 p.m.
On Sat, 3 Apr 2004, Martin Alderson wrote:
After a reboot it seems to have fixed itself. Hopefully it was just a
one off bug of some sort and won't occur again.
A reboot fixes all lockups because locks are either done with futexes
(basically a mutex of sorts which is held in memory), and the transaction
lock is done via locking a file, which also is ultimately implemented in
memory as far as I know.
Wish you could have got a back trace, though, because I want to know if
other people are still seeing the scriptlet "hang" as I am. Thanks
anyway.
Also, is it common for up2date to just lock up? It seems to for me
very
much so I just use the up2date applet thing and launch synaptic to
update. What are other people's views on this
Well, up2date can have bugs...don't know if any of the new code ever opens
the rpmdb, and in some instances does not close it. OTOH, updated, yum,
aptget, and the rpm cli itself are all slaves to librpm so if anything
goes wrong there you can be sure you will see them in those programs.
Cheers...james
P.S. Since you have experience a hang, that have been the one I am
looking at, if you had the time, there is a test harness you can run
against rpm at rpm-devel.colug.net. It runs against a copy of your
system database with anoxious test packages, so its pretty safe to run
on your system. If you would like to give this a whirl, you can email me
directly for any help on setting up the test harness and interpretting a
hang if you see one.
7342
days inactive
7343
days old
6 comments
4 participants
participants (4)
-
Gene C. -
James Olin Oden -
Martin Alderson -
Paul Nasrat