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

[Panu Matilainen <pmatilai welho com>]

On Mon, 2003-04-07 at 17:19, Jeff Johnson wrote:
> 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.

You saying that signals are blocked as needed automatically for anybody
opening the rpmdb? On rpm-4.2 as shipped with RH 9? Don't see that
happening here, I have to do signal(SIGINT, SIG_IGN); ..etc to apt after
opening the db to prevent from being killed by ctrl-C -> leaving locks
around -> hang rpm...

	- Panu -