Hide Forgot
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:
Created attachment 124588 [details] Patch to rpm so signal handlers are only installed when rpmdb is open for write
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
This bug was opened for paul nasrat to view. Reopening.
NEEDINFO_ENGINEERING then.
NEEDINFO_ENGINEERING is not the correct state for this to be in, it has specific context as part of the errata process.
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.
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.
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.