Description of problem: Let pirut only running and doing nothing , it holds yum lock - its not needed. Version-Release number of selected component (if applicable): pirut-1.3.28-17.el5 How reproducible: always Steps to Reproduce: 1. start pirut 2. use yum; yum repolist Actual results: [root@dhcp-28-219 ~]# pirut & [1] 10277 & [root@dhcp-28-219 ~]# yum repolist Loaded plugins: rhnplugin, security Existing lock /var/run/yum.pid: another copy is running as pid 10277. Expected results: when pirut is idle and doing no updates there is no need to hold lock. Additional info:
Yeh, it is needed ... it's basically a running version of yum, with a GUI, kind of like if you started yum shell, and left it open. So if any of the yum data changes under it, bad things will happen.
So why shouldn't the lock time out (perhaps configurably), and a refresh happen when activity resumes? (Somewhat like a web session timing out due to inactivity.) We've already seen this behavior interfere with other use of yum. Not only does the pirut user lose data when the process is tracked down and killed, but others get to figure out what's holding the lock and then kill it off... Are any other system-wide services blockable so quietly and easily? Is it obvious to users that leaving pirut idle will inconvenience all other potential users of yum? The behavior might be okay on a single-user system, but should be re-thought for multi-user/multi-admin systems. Please re-consider the 'CantFix'.
If you are really worried about it, feel free to open an RFE against pirut to work out when it's been "idle" for too long and then auto shutdown. That's probably not trivial (esp. given the lack of outside testing we get on it now), but might be doable.