[Cialug] Fedora - the dreaded rpmq failure

[David Champion]

Well... good theory, but:

]# chkconfig --list yum-updatesd
yum-updatesd    0:off   1:off   2:off   3:off   4:off   5:off   6:off

As far as I know, we've never run yum-updatesd on this box.

In that thread, one of the replies says:

"There is only one rpmdb and it is maintained, queried and updated in
essentially the same manner whether you use rpm, yum commands, pup GUI
interface, smart or the yum-updatesd daemon and whichever process you
use to install updates should be of no consequence."

I agree with this guy - I think the root of the problem is something do
do with the db, and not with what you're interfacing it with. It may be
that yum-updatesd is hitting the rpm db frequently on some systems,
therefore more likely to encounter a problem, but if you run anything
against a flaky db all the time, eventually it's going to crap out.

If you were to trace down what's actually hanging in yum-updatesd, it's
probably something accessing the rpm db, much like rpmq hanging.

Just my opinion / rant, but RH tends to either use old versions of libs
with backports applied, or uses odd compile options that make things
slower or behave differently. One example of this - compare the
performance of mysql on an identical RH box to that of a Mandriva box -
the Mandriva box will run queries much faster than RH, even tried this
running identical configs and databases. In this specific case, I could
get the query down to a few hundredths of a second in Mandriva, but
would take about 15 seconds in RH. Did some research and found that RH
uses some build options in their mysql build (don't recall exactly what
they were) - so unless you wanted a custom-built mysql binary, you're
stuck with slower performance in RH. I don't know that this is the
problem with the Berkely DB, but I wouldn't be surprised.

-dc


Tom Pohl wrote:
> I guess I didn't state it before, but in the cases I've seen of rpm
> databases becoming corrupt, the root cause has been surrounding yum
> (usually when repositories are getting updated or multiple repositories
> are unavailable (ok, there was one time a LONG time ago on a slackware
> box when I was playing with rpm and it's db got corrupt, but that was my
> fault)).  I love yum, but I still feel that it needs to be run manually
> because of the small percentage of the time when there are issues.
> 
> Ok, I found my FC6 box, and you're right there is no yum cronjob, but
> there is yum-updatesd in /etc/init.d.
> 
> Here's a quick link to someone else who suspects similar issues:
> http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=33670&forum=10&post_id=148732
> 
> 
> -Tom
> 
> 
> 
> On Aug 7, 2007, at 1:25 PM, David Champion wrote:
> 
>> I don't see that there's any yum related cron jobs on this box (FC6).
>> I'm not saying that a conflict like this couldn't be the initial cause
>> of the problem, but it seems that the end result is a corrupted Berkely
>> DB file, not a lock issue.
>>
>> -dc
>>
>> Tom Pohl wrote:
>>> Sorry, I had a centos box that I was on when I wrote that.
>>>
>>> Looking at one of my Fedora Core 4 boxes, I wonder if there is conflict
>>> between the cron.daily script yum and the cron.daily rpm script that
>>> gives you a locking issue.  Looking at the run-parts script, it appears
>>> that rpm would run before yum nightly.  Is it possible that the previous
>>> night's yum script got hung up and the next night, rpm becomes grumpy
>>> waiting for the lock to release?
>>>
>>> -Tom
>>>
>>>
>>> On Aug 7, 2007, at 1:08 PM, David Champion wrote:
>>>
>>>> Tom Pohl wrote:
>>>>> Bah, just turn off yum-updatesd and I bet the problem goes away :)
>>>>>
>>>>> Who really wants updates to automatically download / download &
>>>>> install
>>>>> anyway?
>>>>>
>>>>> -Tom
>>>>
>>>> Not running yum-updatesd. This is the job that is hanging nightly...
>>>>
>>>> # cat /etc/cron.daily/rpm
>>>> #!/bin/sh
>>>>
>>>> /bin/rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}.rpm\n' 2>&1 \
>>>>         | /bin/sort > /var/log/rpmpkgs
>>>>
>>>>
>>>> Probably not mission-critical. I removed the script until I get this
>>>> fixed. There's a nearly identical version of this script in Mandriva
>>>> (just has the absolute paths removed from the bins), and it works fine.
>>>>
>>>> -dc
>>>>
>>>> _______________________________________________
>>>> Cialug mailing list
>>>> Cialug at cialug.org
>>>> http://cialug.org/mailman/listinfo/cialug
>>>
>>> _______________________________________________
>>> Cialug mailing list
>>> Cialug at cialug.org
>>> http://cialug.org/mailman/listinfo/cialug
>>>
>>
>>
>> _______________________________________________
>> Cialug mailing list
>> Cialug at cialug.org
>> http://cialug.org/mailman/listinfo/cialug
> 
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug
>