Bug 183882 - pup fails to remove lock file after invocation, LockError lockfile doLock
pup fails to remove lock file after invocation, LockError lockfile doLock
Product: Fedora
Classification: Fedora
Component: pirut (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Depends On:
  Show dependency treegraph
Reported: 2006-03-03 06:44 EST by David Timms
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-03 12:51:49 EST
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 David Timms 2006-03-03 06:44:06 EST
Description of problem:
Since 2006-03-02, pup works OK and succeeds on first invocation, but if started
again within the same session it has exception.

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

How reproducible:
Every time on second run.

Steps to Reproduce:
1. pup
2. apply
3. exit
4. pup
Actual results:
Component: Software Updater
Summary: TB68c720bd __init__.py:510:doLock:LockError: None

Traceback (most recent call last):
  File "/usr/sbin/pup", line 370, in ?
  File "/usr/sbin/pup", line 366, in main
  File "/usr/sbin/pup", line 342, in run
  File "/usr/sbin/pup", line 161, in doRefresh
  File "/usr/lib/python2.4/site-packages/pirut/__init__.py", line 137, in reposSetup
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 510, in doLock
    raise Errors.LockError(0, msg)
LockError: None

Local variables in innermost frame:
mypid: 4318
self: <__main__.PackageUpdater object at 0xb7a451cc>
oldpid: 2531
fd: <open file '/var/run/yum.pid', mode 'r' at 0xb7a65a88>
msg: Existing lock /var/run/yum.pid: another copy is running. Aborting.
lockfile: /var/run/yum.pid
root: /

Expected results:
Pup runs a second time normally within the one session.

Additional info:
1. The lock file mentioned does exist.
# ls -l /var/run/yum.pid
-rw-r--r-- 1 root root 4 Mar  3 21:23 /var/run/yum.pid
2. erasing above file allows it to start normally again
# rm /var/run/yum.pid
3. Reboot seems to clear the yum.pid and it works OK.
4. Once pup has run once:
  a. yum exits with # yum update
    Loading "installonlyn" plugin
    Existing lock /var/run/yum.pid: another copy is running. Aborting.
  b. pup and pirut have the-
Exception Occurred
An unhandled exception occurred, with the trace given above.
5. The fault is failing to clear the lock file when exiting.
6. is this caused by solution to ?
Comment 1 David Timms 2006-03-03 07:36:47 EST
* Fri Mar 03 2006 Jeremy Katz <katzj@redhat.com> - 1.0.0-1
- Catch locking error (#183685)

The above solution has placed a nice dialog on the exception (Another
application is running that is accessing software information), but doesn't stop
the root cause of pup failing to clear the lock file.

After reboots, and trying a few things, I found that if there are no updates (or
you dont want to update) if I use the top-right X to exit pup rather than via
the quit button when it is showing which packages are available, then it closes
the GUI window, but leaves pup running: $ ps aux|grep pup
davidt    2573  0.1  0.7  14076  3924 ?        S    23:33   0:00 /usr/bin/pup
root      2574  0.0  0.2   5644  1352 ?        S    23:33   0:00
/usr/sbin/userhelper -w pup
root      2577 11.6 12.8 121076 66496 ?        S    23:33   0:02 /usr/bin/python
-tt /usr/sbin/pup
davidt    2580  0.0  0.1   3880   664 pts/0    R+   23:33   0:00 grep pup

The "still running" exception is then triggered.
Comment 2 David Timms 2006-03-03 07:54:36 EST
$ su -
# pup
/usr/lib/python2.4/site-packages/yum/config.py:439: DeprecationWarning:
getConfigOption() will go away in a future version of Yum.
Please access option values as attributes or using getattr().
-----click X
-----window disappeared but nothing else happened!, no prompt returned.
Comment 3 Jeremy Katz 2006-03-03 12:51:49 EST
Okay, not sure why connecting the delete_event via glade wasn't working.  For
now, done by hand and will be in 1.0.1
Comment 4 David Lawrence 2006-06-27 21:41:10 EDT
Moving component to pirut. Sorry for the spam.

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