Bug 181434 - rpm should only install termination signal handlers when rpmdb is open for writing
rpm should only install termination signal handlers when rpmdb is open for wr...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-13 17:47 EST by Menno Smits
Modified: 2014-01-21 17:53 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-10 06:03:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to rpm so signal handlers are only installed when rpmdb is open for write (1.51 KB, patch)
2006-02-13 17:50 EST, Menno Smits
no flags Details | Diff

  None (edit)
Description Menno Smits 2006-02-13 17:47:08 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060203 Fedora/1.5.0.1-1.1.fc4.nr Firefox/1.5.0.1

Description of problem:
rpm installs handlers for terminating signals whenever it opens rpmdb. This is to help prevent an inconsistent rpmdb state if a termination signal is received while the rpmdb is being modified.

This poses a problem for software such as Yum which use the rpm bindings as they cannot correctly handle signals for themselves. Specifically for Yum, CTRL-C during package downloads does not work as expected.

The attached patch fixes this problem so that rpm only installs the signal handlers when it truly needs to: when the rpmdb is open for write. This means that users of the rpm libraries have more opportunity to handle signals themselves and will fix the CTRL-C problem in Yum mentioned above.

Version-Release number of selected component (if applicable):
rpm-4.4.1

How reproducible:
Always

Steps to Reproduce:
Not required. Problem has already been described above.
  

Additional info:
Comment 1 Menno Smits 2006-02-13 17:50:49 EST
Created attachment 124588 [details]
Patch to rpm so signal handlers are only installed when rpmdb is open for write
Comment 2 Jeff Johnson 2006-02-13 18:15:26 EST
Not the correct fix.

Even if the database is opened RO, there is still a need to write locks to __db* files,
and early exit from signal can leave a shared lock that prevents exclusive locks
Comment 3 Seth Vidal 2006-02-13 19:50:13 EST
This bug was opened for paul nasrat to view. Reopening.

Comment 4 Jeff Johnson 2006-02-15 11:25:30 EST
NEEDINFO_ENGINEERING then.
Comment 5 Paul Nasrat 2006-02-15 12:01:00 EST
NEEDINFO_ENGINEERING is not the correct state for this to be in, it has specific
context as part of the errata process.
Comment 6 Jeff Johnson 2006-02-15 12:09:18 EST
Well rather than discuss the state of the bug, and who can see the patch, perhaps we should discuss
the patch, shall we?

Conditioning the signal handler on whether the database is being opened RO is very much the wrong 
thing to do, and risks leaving stale locks.

If you want ^C handling in yum the choices are (as I've told you before):

1) being careful about when the database is opened.

2) exposing the same signal bit mask to the bindings so that ^C can be detected whenever.

Other alternatives include

3) adding infrastructure to chain signal handling out of rpmlib. I'd really not like to go there,
life with signals is touch enough without wiring signal chaining (and lots of implicit programming
rules on how to use) into an API.
Comment 7 James Olin Oden 2006-02-22 11:11:20 EST
Just adding something from experience in the field on real live systems.  
Having any stale locks hanging around whether they be read or write locks is 
just bad.  What you end up with a transaction that locks up in the middle 
somewhere.  What do you do with this?  Well you have to kill rpm hard.  No 
rollback in this situation, just painfull cleanup as you try to determine just 
what has actually occured on the system, which involves reading scriptlets that 
have already ran.  This is very painful, and does not foster customer trust (I 
am speaking of my own customers now).   

So, from my perspective, a solution that does not have librpm signal handlers 
active while doing a read on the DB is very bad.
Comment 8 Panu Matilainen 2007-08-10 06:03:17 EDT
Like explained in c#2, even readonly operations need to deal with locks. Since
Berkeley DB cannot be safely closed from a signal handler, the "polling for
signals" approach is the only viable solution without some major rearchitechting.

Fixed in rawhide a while ago by providing means to check for rpmlib caught
signals from python and a patch to yum to use it.

Note You need to log in before you can comment on or make changes to this bug.