Retired

Reason for Retirement: Please confirm if this is still a problem in the latest
version of Smart.

Please reopen this issue in the new bugtracker if it is still an issue.
New Bugtracker : http://bugs.launchpad.net/smart
further details:
https://blueprints.launchpad.net/smart/+spec/bug-reporting-migration.

Em Qua, 2006-11-22 às 15:07 +0000, Axel Thimm at Labix Tracker escreveu:

> Other than that there is also ksmarttray that asyncronously accesses the rpmdb
> through smart invocations, some (smart update) even as suid root. Could that be

There are no reports about that sort of problems with ksmarttray on any
other distribution.

> Is it possible that Fedora has some sort of regular checking on the
> background or even cron job that would query the RPM base?

There is, but only if you have installed yum.

Other than that there is also ksmarttray that asyncronously accesses the rpmdb
through smart invocations, some (smart update) even as suid root. Could that be
an issue? I don't know if the reporters were using ksmarttray, but if it's a
possible problem I'll check on them.

Em Qua, 2006-11-22 às 13:18 +0000, Axel Thimm at Labix Tracker escreveu:

> The user was only using smart, neither apt, nor yum. See the following post

I don't know about Fedora, but in SUSE there is a ZenWorks daemon that
is installed by default and is aways started. I've seen reports of
people receiving the mesage that the rpmdb was locked while running
Smart even without having yum or yast running, which was probably caused
by some query coming from the 'zmd'. 

Is it possible that Fedora has some sort of regular checking on the
background or even cron job that would query the RPM base?

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

>
> Axel Thimm <Axel.Thimm@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

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 [...]

As mentioned by Jeff Johnson:
http://lists.labix.org/pipermail/smart-labix.org/2006-November/002336.html

It's possibly an RPM DB corruption caused by YUM.
https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-November/001858.html

Please, spend some time *not* using YUM, or even removing it from your system.

Report back if the problem persists.

Is this still an issue? What version of smart/rpm?

Submitting on behalf of a user at ATrpms. Recently some users have reported
issues with smart on FC5.

==================================================================

Hi,

>>> I also suffered from a lot of smart/rpm problems on my FC5 box this
>>> week and I still haven't figured out what caused it. It seems like
>>> smart kept corrupting my rpm database (happened over night at least
>>> twice and a couple more times when I was trying to fix it). I've
>>> rebuilt my rpm db at least 10 times and removed all smart data (except
>>> for config) at least twice.

And it just happened again. I'm running a smart transaction (upgrade
mythtv + small misc updates, remove two old kernels + kmdls) and smart
just hangs during  "Committing transaction":
Committing transaction...
Preparing...                    ########                               ( 21%)

I can see that it's looping in librpm somewhere (__memp_fget_rpmdb), so
I'm guessing my rpm db is corrupt (once again). Now, after rebuilding the
rpmdb several times and removing all smart data (except for config) at
least twice, the transaction still would not complete without hanging up.

Then, I split up the transaction into the upgrade and the removal of the
kernels. The package upgrade was fine, but the removal of the kernel +
kmdls hung up smart (again). I finally decided to give up and just rpm -e
them on the command line; no problems there.

Mark