Bug 195757 - yum-updatesd locks out pirut and oter yum-based apps (kyum)
yum-updatesd locks out pirut and oter yum-based apps (kyum)
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Depends On:
  Show dependency treegraph
Reported: 2006-06-17 04:14 EDT by G.Wolfe Woodbury
Modified: 2014-01-21 17:54 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-19 16:33:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description G.Wolfe Woodbury 2006-06-17 04:14:37 EDT
Description of problem:
  The yum-updatesd service is enabled by default in the current rawhide
(2006-06-16) install and it locks out other users of yum.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

the yum-updatesd service need to find some way to not prevent the use
of yum from the CLI or Pirut.

I thought policy was to not enable services like this by default?
Comment 1 Seth Vidal 2006-06-17 10:17:48 EDT
1. it only holds the yum lock for a few seconds while it gets the metadata and
parses it.
2. this is an enabled daemon b/c it:
   a. doesn't listen on a port
   b. doesn't do anything except notify the user of available updates.

Comment 2 G.Wolfe Woodbury 2006-06-17 10:29:30 EDT
In this case the lock was being held for more than ten minutes while I was
attempting to get some things installed.  It was far more than a few seconds.
Comment 3 Jeremy Katz 2006-06-17 22:38:40 EDT
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
Comment 4 G.Wolfe Woodbury 2006-06-17 23:44:15 EDT
Not using either here.
The module from ~katzj fails with an import error: no module named 'callback'

I will note that I changed the repository info while yum-updatesd was running.
Restarting the original service now yeilds no error with kyum.  Does the other
reporter have a similar case?
Comment 5 Jeremy Katz 2006-06-18 09:42:39 EDT
... that'll teach me to not cvs update before working with my CVS copy of yum :-)

Fixed the silly error and updated the copy on my people page.  Changing the
repository info shouldn't matter as we reread repo information on every metadata
Comment 6 Jeremy Katz 2006-06-19 16:33:29 EDT
Based on information from fedora-test-list, I'm going to assume this is fixing
this.  If it's not, please reopen.

The fix will be in yum 2.9.1-1 which will be out once rawhide unlocks from the
test1 freeze.

Note You need to log in before you can comment on or make changes to this bug.