On Tue, 3 Jul 2007, seth vidal wrote:
On Tue, 2007-07-03 at 08:42 -0400, Konstantin Ryabitsev wrote:
Hi, all:
Just a reminder that it's still impossible to exit yum using Ctrl-C or
Ctrl-\. It always just switches to a different mirror, no matter how
quickly or frequently I press ctrl-c or ctrl-\. I believe it was
claimed "fixed" several times in the past, but it still is not working
as of 3.2.1. This means that if you're using mirrorlists, yum is
near-impossible to exit.
There should be a way to interrupt yum, at least during
package/metadata download. That's very basic functionality, and it is
missing. Having to Ctrl-z and then kill -9 is not very friendly to
users nor admins.
okay, I'm open to suggestions. The last time we stepped around the
problem using menno's work for an opportunistic access to the rpmdb it
was purported that we were corrupting the rpmdb. That may or may not
have turned out to be the case as there was another kernel mmap issue at
the same time. However, I'm game to figuring out ways of fixing this
issue w/o waiting for rpm modifications to occur.
Do we want to try menno's patch to the rpmdb access again? Or are there
other suggestions?
Well, to quote Jeff from
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181434#c6:
---
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.
---
Yum is now in far better shape for 1) than it was before, because it
doesn't have to download tons of headers and feed into rpm for dep
resolution.
Part of the pain could possibly be migitated by tricking (or enabling
requesting it through the bindings) rpmlib into using private locks for
readonly db operations. That alone wont fix the ctrl-c issue (without
further rpm modifications) but it does avoid creating stale systemwide
locks. This isn't fixing the issue though, it's more like looking away to
avoid seeing the problem :)
Adding proper signal handling/passing, be it 2) or 3) or whatever variant
I'm going to look into anyway.
Oh and then there's another locking related issue I just noticed when
looking at this: yum (and any related code like plugins, pirut etc)
tracebacks can leave stale rpmdb locks around. I suppose yum could insert
a global exception handler whenever a ts is active to clean up any rpmdb
accesses. I'm going to have a look at mopping up the locks on tracebacks
at bindings level anyway, and sooner than later I hope.
- Panu -
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
