Bug 183882 - pup fails to remove lock file after invocation, LockError lockfile doLock
Summary: pup fails to remove lock file after invocation, LockError lockfile doLock
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pirut
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-03 11:44 UTC by David Timms
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-03-03 17:51:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David Timms 2006-03-03 11:44:06 UTC
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):
pirut-0.9.17-1

How reproducible:
Every time on second run.

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

Traceback (most recent call last):
  File "/usr/sbin/pup", line 370, in ?
    main()
  File "/usr/sbin/pup", line 366, in main
    pup.run()
  File "/usr/sbin/pup", line 342, in run
    self.doRefresh()
  File "/usr/sbin/pup", line 161, in doRefresh
    self.reposSetup(pbar)
  File "/usr/lib/python2.4/site-packages/pirut/__init__.py", line 137, in reposSetup
    self.doLock(YUM_PID_FILE)
  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 ?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183311

Comment 1 David Timms 2006-03-03 12:36:47 UTC
pirut-1.0.0-1
-------------
* Fri Mar 03 2006 Jeremy Katz <katzj> - 1.0.0-1
...
- Catch locking error (#183685)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=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 12:54:36 UTC
$ su -
Password:
# 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().
  DeprecationWarning)
-----click X
-----window disappeared but nothing else happened!, no prompt returned.

Comment 3 Jeremy Katz 2006-03-03 17:51:49 UTC
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-28 01:41:10 UTC
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.