[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-id: <677E53C2-1444-4EB3-AE07-4CA3FE740340@mac.com>
Date: Sun, 29 Mar 2015 12:14:58 -0400
From: Jeffrey Johnson <n3npq@....com>
To: owl-dev@...ts.openwall.com
Subject: Re: Re: removing /var/lib/rpm/__db.00? on rpm upgrade (was:
recent updates)
On Mar 29, 2015, at 5:56 AM, Solar Designer wrote:
> Hi Jeff,
>
> I am sorry I didn't reply sooner. As you can see, things are very slow
> here, but it looks like Vasily Kulikov will work on bringing Owl more
> up-to-date this year - so we should see some activity, and hopefully by
> you and others as well.
>
No worries.
> On Sat, Feb 21, 2015 at 03:47:22PM -0500, Jeffrey Johnson wrote:
>> I've just joined owl-dev@ mailing list and
>> will be trying to install 3.1-stable and current
>> in the next few days
>
> Great. How did it go?
>
Well enough.
FYI, rpm5.org does CI including coverage tests installing into a chroot.
I have used various distros with sane and sober *.prm packages over the years,
most recently OWL2 with the intent to move to OWL3.
The problem I need to solve is to find a stable set of packages that I can
randomize and find packaging problems and test rpm5 development changes.
Increasingly distro politics determines how packaging SHOULD be done, and
QA on RPMS is seldom more than
WORKSFORME
which is insufficient to find missing dependencies.
Communicating the problems has almost become more effort than creating my own linux
distribution, but I am still looking closely at OWL3, PLD, and Poky/Yocto as modern linux
distributions that do careful work and don't change every other day in unpredictable ways.
>>> %triggerpostun -- %name < 4.2-owl22
>>> # Remove __db.00? files that look like they're pre-NPTL. We may be removing
>>> # files that are opened and/or memory-mapped by us (by the rpm process that
>>> # installs the new rpm package), but that's OK. The next invocation of rpm
>>> # will recreate the files. 4.2-owl22 is when we added this trigger, and we
>>> # were already using NPTL at the time, so there is no need to perform the
>>> # size check and possibly remove the files when upgrading from newer versions.
>>> RPMDBDIR=/var/lib/rpm
>>> if [ -f $RPMDBDIR/__db.001 -a "`wc -c < $RPMDBDIR/__db.001`" -le 8192 ]; then
>>> rm -f $RPMDBDIR/__db.00?
>>> fi
>>
>> You shouldn't simply remove __db.00? files even if that "works".
>> At a minimum, run
>> db53_recover -h /var/lib/rpm
>> in %posttrans where /var/lib/rpm is quiescent.
>
> Oh. What harm is there in removing these files?
>
All depends on what problem you are attempting to solve.
The conversion to NPTL was first solved (like 10+ y ago) with an rpmlib(NPTL) (from memory) tracking
dependency to ensure that rpm itself could not be upgraded without manual intervention.
This was later changed to call getconf(3) dynamically
Requires: getconf(GNU_LIBPTHREAD_VERSION) = NPTL
which is the bog-standard way of detecting whether NPTL is in use.
But the __db* files are not file locks. Rather, the __db* files are a registry
for NPTL locks connected to futexes. Removing the files may cause disparate
locking schemes from competing processes, and can lead to stale futexes.
Running dbXY_recover will notify other users of the shared resource to error out.
The other problem is using a trigger, which will fire in the middle of installing
a set of packages, a complicated context to debug. The perhaps better approach
is to use a %posttrans script rather than a trigger, where an rpmdb has a better chance
of being quiescent.
(aside)
rpm5 uses transactional locking and automates running DB_RECOVER where
needed, so ancient lore like "rm -rf /var/lib/rpm/__db*" and "rpm --rebuilddb"
needs to evolve to using Berkeley DB tools as intended, not ad hoc.
Meanwhile, the issues I point out are pedantic: do as you wish, worst that happens
is that you have to reinstall.
>>> We probably need a similar section for the recent rpm update as well.
>>> Would both sections fire when upgrading from even older rpm, though
>>> (prior to 4.2-owl22)? Would that be OK? I guess so, but perhaps the
>>> old section above will become redundant, and thus we need to replace it
>>> rather than add another? This needs some thinking and testing.
>> Let me catch up with Owl packaging and I'll try to send along a patch.
>
> We'd appreciate a more proper patch, yes.
>
todo++ let me see if I can get OWL3 into virt-manager soonishly
73 de Jeff
> Thanks,
>
> Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
