Bug 195757

Summary: yum-updatesd locks out pirut and oter yum-based apps (kyum)
Product: [Fedora] Fedora Reporter: G.Wolfe Woodbury <redwolfe>
Component: yumAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: katzj, valdis.kletnieks
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-06-19 20:33:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description G.Wolfe Woodbury 2006-06-17 08:14:37 UTC 
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:
always


Steps to Reproduce:
1.
2.
3.
  
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 14:17:48 UTC 
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 14:29:30 UTC 
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-18 02:38:40 UTC 
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-18 03:44:15 UTC 
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 13:42:39 UTC 
... 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
update.
Comment 6 Jeremy Katz 2006-06-19 20:33:29 UTC 
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.