Re: Lockup safety in rpm-4.1.1 and rpm-4.2

[Jeff Johnson <jbj redhat com>]

On Sun, Apr 06, 2003 at 04:24:32PM -1000, Warren Togami wrote:
> Despite improvements in rpm-4.1.1 and rpm-4.2, lockups still occur in
> several cases, especially after CTRL-C aborting from popular package
> management tools like apt-get or yum.
> 
> The following is Red Hat Linux 9.0 with rpm-4.2-0.69 and
> apt-0.5.5cnc4.1-0.fdr.5.rh90 from Fedora stable.

Try with rpm-4.2-1 please. A refcount on the database prevented
close (leaving stale locks), and cursors, not just the databases,
are individually closed in rpm-4.2-1 as well.

> 
> At this point the only thing you can do is kill -9 rpm and remove
> /var/lib/rpm/__*.
> 

And, if you use "kill -9" then it's up to you, not rpm, to do
	rm -f /var/lib/rpm/__db*

> 
> Solutions?
> Can apt, yum and other package managers possibly be modified to unlock
> before aborting?

Only by trapping signals in apt/yum/etc. I suspect that 2 levels of signal
handling is not for the faint of heart.

> 
> Should apt, yum and other package managers be forbidden from aborting at
> certain types like rpm?  (CTRL-C doesn't do anything.) 

Applications that use rpm are already prevented from aborting. Signal handlers
are enabled when rpmdb is opened, signals are blocked where needed.

kill -9 is a whole different issue.

> 
> Has anyone found situations where something other than aborting a
> package management tool causes rpm lockups?
> 

There are deadlocks possible if you misuse the API, that's true for any
database. For example, there was a report of attempting to traverse
the database using perl bindings, invoking "rpm -e" for each item.

That instantly deadlocks, as there is a cursor and locks on the object,
so "rpm -e" instantly deadlocks.

> Is there any possible solution to improve rpm's behavior?

You need to be much more specific here. Improve how?

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC