[issue239] smart hanging on librpm/__memp_fget_rpmdb

[Jeff Johnson]

On Nov 22, 2006, at 8:18 AM, Axel Thimm at Labix Tracker wrote:

>
> Axel Thimm <Axel.Thimm at ATrpms.net> added the comment:
>
> The user was only using smart, neither apt, nor yum. See the  
> following post
>
> http://lists.atrpms.net/pipermail/atrpms-users/2006-October/ 
> 006181.html
>> Nope, I only have smart enabled. I don't even have apt or yum  
>> installed.
>
> Furthermore the changes from a working setup and the broken one were
>> [...] The only updates that I see that can have any impact are
>> kernel (2.6.18) and libsepol. And for that last one, I don't have
>> selinux enabled [...]
>

It would be useful to know whether the problem is occurring while
smart is running, or is occurring between smart runs.

Basically, doing
	rm -f /var/lib/rpm/__db*
before any smart execution should (I predict) make smart run more
predictably because it eliminates the possibile randomness induced
by a damaged rpmdb cache.

One does have to insure that nothing else, like a 2nd smart run in  
background,
or the cron driven query that lists what packages are installed,  
occurs, as removing
the cache also removes the names of posix locks used to insure cache  
coherency.

There are means to add exclusive locking to smart, but that's not gud  
enuf, because any
additional locking scheme requires other applications to participate.

Meanwhile, there are "private" and "lockdbfd" attributes that can be  
added to
an rpmdb open, both or neither please, to change locking used. I'd  
suggest letting
Gustavo decide if its worth attempting a different locking mechanism  
however.

73 de Jeff