3:34 a.m.
Just installed rawhide of 2006-06-16 on my test machine (work1.private)
It successfully installed, despite 4 or 5 unresolved dependences
(Helix requires mozilla-plugins?)
The real killer is, however, that the yum-udatesd service is enabled by default
and it locks out the command line use of yum and all the yum-dependent apps like
Pirut, KYum and YumEx.
Bugzilla is #195757 (against yum)
--G.Wolfe Woodbury
6:43 p.m.
On Sat, 2006-06-17 at 04:34 -0400, G.Wolfe Woodbury wrote:
The real killer is, however, that the yum-udatesd service is enabled
by default
and it locks out the command line use of yum and all the yum-dependent apps like
Pirut, KYum and YumEx.
It's intentionally enabled by default (otherwise, the desktop side of
things hardly works :), but it shouldn't be locking everything out
except during the time period that it's actually checking for available
updates.
Can you strace the yum-updatesd process to see what it's doing?
Jeremy
8:18 p.m.
On 6/17/06, Jeremy Katz <katzj(a)redhat.com> wrote:
Can you strace the yum-updatesd process to see what it's doing?
I'm seeing the same and mine is doing this:
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 100) = 0
gettimeofday({1150593247, 704717}, NULL) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9f5add8, FUTEX_WAKE, 1) = 0
gettimeofday({1150593247, 706566}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 100) = 0
gettimeofday({1150593247, 803803}, NULL) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9d43d28, FUTEX_WAKE, 1) = 0
futex(0x9f5add8, FUTEX_WAKE, 1) = 0
gettimeofday({1150593247, 805680}, NULL) = 0
ad infinitum
--
jgb
9:46 p.m.
On Sat, 2006-06-17 at 21:18 -0400, Jason Boyles wrote:
On 6/17/06, Jeremy Katz <katzj(a)redhat.com> wrote:
> Can you strace the yum-updatesd process to see what it's doing?
I'm seeing the same and mine is doing this:
Can you try http://people.redhat.com/~katzj/yum-updatesd.py and see if
that works better (should just be able to replace /usr/sbin/yum-updatesd
with it)?
Basically, I'm guessing that you're in a situation where you're either
using NM or bringing networking up by hand and so we hit a traceback
when getting repo information and then never unlock the lock file
Jeremy
11:49 a.m.
On 6/17/06, Jeremy Katz <katzj(a)redhat.com> wrote:
Can you try http://people.redhat.com/~katzj/yum-updatesd.py
[...]
Basically, I'm guessing that you're in a situation where you're either
using NM or bringing networking up by hand[...]
You're right, I'm using NM and not bringing the network up at boot time.
After replacing my /usr/sbin/yum-updated with your patched version it
isn't holding the yum lock anymore. So that seems to resolve it.
--
jgb
2:54 a.m.
On Sat, Jun 17, 2006 at 07:43:56PM -0400, Jeremy Katz wrote:
It's intentionally enabled by default (otherwise, the desktop
side of
things hardly works :), but it shouldn't be locking everything out
except during the time period that it's actually checking for available
updates.
Ouch, that'll be very very unpleasant for anyone on GPRS with a mobile phone
or any other pay by volume service. I trust that'll get fixed for the final
release, or should I file a bug ?
Alan
6521
days inactive
6522
days old
5 comments
4 participants
participants (4)
-
Alan Cox -
G.Wolfe Woodbury -
Jason Boyles -
Jeremy Katz