Re: Re: SUG: Automatic RPM database verification and repair

[Tony Nelson <tonynelson georgeanelson com>]

At 9:05 AM -0500 11/29/06, Jeff Johnson wrote:
>On 11/28/06, Tony Nelson <tonynelson georgeanelson com> wrote:

>> True.  It would be a good thing if RPM did such checks.

>We disagree, at least on the frequency of checking and the amount of
>automation.

OK.


>So create problem reports. The current problem reports have to do
>with stale locks and __db cache corruption, not with Packages or --verifydb.

RH BZ 215127.


>> I hope rpm-verifydb will create more problem reports.  Currently, problems
>> in the RPM database can go unnoticed for a long time, until disaster
>> strikes.

>If a tree falls in the forest, who hears the noise?

Only the end-user it falls on.


>> I chose "rpm --verifydb" over some Berkely DB tool as I expect that rpm
>> already does proper locking of its database during checks (modulo any
>> kernel bugs).
>>
>
>RPM with concurrent access uses exactly Berkely DB locks, there really
>is no meaningful difference between --verifydb and rpmdb_verify.

Nor did I claim that there was.  "rpmdb_verify" is part of RPM, not part of
Berkely DB.


>The external executable is preferred to simplify rpm options (there are
>far too many) and to provide better doco (of which there is far too little)
>for verifying an rpmdb.

There is no man page for rpmdb_verify in FC6.


>>>>With FC6 there has been a spate of RPM database corruption. It happened
>>>>to me: though there may have been incipient corruption in my FC5, after
>>>>--rebuilddb and upgrading successfully I found more corruption later.
>>>>This brings up that the RPM database is just assumed to work, but isn't
>>>>being checked until it falls over.
>> >>
>> >
>> >No there has not been a "spate of RPM database corruption".
>>
>> How do you know? 8-)  After all, who's checking now?
>>
>
>Ultimately, noone knows.
>
>Meanwhile, I have years of experience diagnosing and fixing rpmdb
>problems. I am not seeing or hearing that headers were damaged in
>databases (which is my definition of "corruption"). YMMV as always.

I suggest that you supplement your years of experience with actual hard
data, gathered by a daily cron task that checks the RPM database for
corruption and reports that corruption to the user, and to someone at RH or
Fedora -- "yum update" seems a reasonable reporting channel.  (While there
is much angst over counting Fedora installations, counting broken RPM
databases is another matter.  If you are correct, no reports will be sent.)


>Then ask anaconda (or yum) to do run rpmdb_verify or --verifydb or
>call the python method ts.verifyDB() as needed.

That does seem like the course of action that is most likely to produce
benefit.

>When an rpmdb is verified is not solvable in rpmlib
>(except by verifying on every close, been there, done that, dinna help).

It is solvable in the RPM /package/, by installing a cron task much as my
rpm_verifydb package does.


>> Where is rpmdb_verify documented?  "man rpmdb_verify" doesn't find
>> anything.  "apropos rpm" | grep 'verify'" doesn't find anything either.  It
>> doesn't seem to be in "man rpm".

>Look for "db_verify" in the Berkely DB utilities doco, which is also included
>in the db4 package last I checked.

So "rpmdb_verify" is not documented anywhere?  It should be documented in
RPM's documentation, which could assert that it is the same as "db_verify"
in the Beredely DB docs.


>> RPM users would benefit from having that documented some place RPM (other
>> than this list).  "man rpm" is where they would expect to find it.
>>
>
>"expect" is in the eye of the beholder.

Exactly.  RPM's users are RPM's customers.  RPM should try to serve them
well, and this includes putting the documentatin for RPM in RPM's own
documentation.


>> OK, though Packages is too large to save every day, and just keeping the
>> last one would mean that the sysadmin would need to notice the problem
>> before that last good copy of Packages was overwritten.  (I have an RPM
>> database instance that has corruption but functioned normally most of the
>> time, though not during an Anacoda upgrade to FC6.  See RH BZ 215127.)  It
>> would seem that it would be better to only save good copies of the Packages
>> file, and to report to a responsible sysadmin that there is an issue (if
>> only there were such a sysdamin for most systems).  I don't know how to do
>> that with "rpm --rebuilddb", but I do know how to do that with "rpm
>> --verifydb".
>>
>
>Too large is a different problem, try "man rdiff" if you want an easy
>incremental
>backup.

I see rdiff is in extras.  I see it uses rsync.  Possibly I will add that
capability to my rpm_verifydb package.


>> /No one/ saves a copy of Packages, as such an implementation detail is
>> RPM's responsibility, and it does not do it.  Don't blame the users for
>> omissions!
>
>We disagree. If you want to protect your data, you need to take precautions.

It disapoints me that you think it is not RPM's responsibility to protect
its database.


>RPM cannot do reliable backups for all possible users under all cases.
>
>Meanwhile, there is nothing stopping you or anyone else from doing whatever
>you wish to achieve reliability.

I understand completely.
-- 
____________________________________________________________________
TonyN.:'    The Great Writ     <mailto:tonynelson georgeanelson com>
      '      is no more.             <http://www.georgeanelson.com/>