On Dec 1, 2006, at 11:47 AM, Tony Nelson wrote: At 6:55 AM -0500 12/1/06, Jeff Johnson wrote:
...
What does signal.default_int_handler do? Exit?
It does the "Python thing" of raising a Python Exception. SIGINT produces a KeyboardInterrupt exception. Any unhandled exception will terminate a python program, but Yum handles KeyboardInterrupt, and either does something useful, such as moving to the next download mirror (that happens in a library), or it terminates gracefully, closing the RPM database cleanly.
Heh, we are having vocabulary problems.
There's lots more (and lots more critical code) to fielding a signal than just raising an exception.
That's the land of rpmlib, in C, not python.
My understanding is that the changes to yum to repeatedly open and close the RPM database are to work around RPM's seizing of SIGINT. I believe this proposal is a cleaner, safer, and more effective workaround for that issue. (More effective in that fewer SIGINTs are eaten by RPM.) I have not received any complaints about Stablemirror from its (very few) users other than that it doesn't work at all on FC6, where it is really no longer needed.
Free ths SIGINT! Bad RPM for preventing yum (and FLOSS) from handling ^C!
(aside) That's a joke, son, perhaps too dry for your taste.
If so, that explains why your database is in need of so much verification.
No, yum is careful about closing the database when it exits. My reading of what RPM does on receipt of a signal and what yum does was that they are equivalent.
And what happens if yum does reach the ppint "it exits". That state is (ahem) less than graceful, and is happening on every segfault, leaving stale locks, users get annoyed and start trying to verify rpm databases. And it is an ASSumption ;-b that my RPM database needs more care than others. I'm merely taking better care of it than most. 8-)
2) RPM's developers could be asked for a new API to tell RPM not to take certain signals. This could be done for FC7.
You ought to make the suggestion on <fedora-devel> and on <rpm-devel> mailing lists.
Well, at the moment, it seems that the two people most involved, you and Seth, are communicating here. If my idea is acceptable, you and Seth will say so, and if Seth requests me to I will poste elsewhere and file a RFE against RPM. If not, my idea won't be used, so a request to enhance RPM would be a waste of your time. Still, if you ask, I'll do those things.
FWIW, rpm has a bit mask, a bit is set for every signal received.
That set of bits has been in rpmlib for years. All that yum needs to do is test the bit, and exit if signal is received.
Reopening a Berkeley DB repeatedly in order to handle ^C et al is nuts.
And that API has been there, and I've pointed out its use to Seth, and to other yum developers, repeatedly, since 2004. To no avail. Seth doesn't always respond to my posts (even if they are in reply to a reply of his to one of my posts). When he does respond, it is usually to day that whatever I've proposed is an unclean hack. He may think that it is cleaner for yum to repeatedly open and close the RPM database than for it to steal back the SIGINT signal, but I don't know.
Free the SIGINT!!! Sigh ...
While you're at it, why don't you create bugzilla reports for every Red Hat, SuSE and Mandrive product as well.
That would be inappropriate, as I don't use those products.
But a solution for RPM (and perhaps for yum) needs to work on linux, not just for Fedora.
But feel free to do whatever with rpm and yum in Fedora. Have fun! 73 de Jeff
|
