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?
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.
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.
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
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?
... 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.
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.