[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: SUG: Automatic RPM database verification and repair

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

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

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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]