On Aug 31, 2010, at 4:23 AM, Roman Gächter wrote:

> Hello
> 
> We run into serious problems with OpenPKG 4.0.2 and 4.0.7 on solaris 10 SPARC 
> in "solaris whole rooted" zones.
> 
> After some days of normal operation our rpm db gets corrupted.
> 
> 

(aside)
"Corrupted" means data loss or integrity failure technically
(although its quite common to hear "corruption" applied
to Berkeley DB with other meanings.)

Is there data loss or integrity failure? Running db_verify

        cd /var/lib/rpm
        db_verify Packages

against Packages or other "tables" (Berkeley DB calls
"tables" databases) will detect integrity failures.

Data loss can be detected by, say, counting the number
of packages installed like
        rpm -qa | wc -l
> We see hanging processes from the the openpkg rc facility.
> The openpkg rc script tests the rpm db with a "openpkg rpm -q openpkg" query.
> These queries hang up.
> 

Hang up how? Can you add -vv to a query? There is also
        cd  /var/lib/rpm
        db_stat -CA     # <-- -CA displays all info, -Cl displays lock info

Note that you MUST use db_verify/db_stat for the same version of
Berkeley DB used by RPM. The tools for the same version of Berkeley DB if 
internal
to RPM are released with RPM.
> When this happens the permission of the rpm lockfiles RPM/DB/__db.001 .002 
> .003 changes to root.
> 
> 
An rpmdb is protected by permissions on /var/lib/rpm.

The associated __db* files are created as needed.

I would expect "root" as owner typically, because /var/lib/rpm is
usually writable only by "root", and rpm installs are typically run as "root".

But the openpkg wrapper appears to have a different ownership model.
> To recover from this problem we have to terminate the rpm queries, cleanup 
> and rebuild the rpm db and to change back
> the permissions of the rpm lockfiles to the openpkg user.
> 
> The building of our openpkg4 binary package could be done without problems 
> with the original openpkg-4.0.7 source package.
> We are using the VALUE license.
> 
> Does anyone had similar problems?
> Any hints to resolve?
> 
> 

Identifying what is causing the "hang" is what is needed first.

hth

73 de Jeff
> Best regards
> Roman
> 

Reply via email to