Bug 607049 - Manual yum update fails: sqlite3 error and pidfile error
Manual yum update fails: sqlite3 error and pidfile error
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
13
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-22 23:21 EDT by Rich Mattes
Modified: 2014-01-21 18:15 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-23 07:26:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rich Mattes 2010-06-22 23:21:02 EDT
Description of problem:
I'm trying to update F-13 manually, via yum.  I tried to run the command "yum update" as root.  All of the packages were downloaded properly, but when yum attempted to run the transaction, an error occurred.  Subsequent calls to yum update elicit a different error, when yum looks for the pidfile.

Version-Release number of selected component (if applicable):
yum-3.2.27-4.fc13.noarch


How reproducible:
All attempts to run a yum update ("sudo yum update" or "su -c 'yum update'" in the terminal) seem to elicit this problem

Steps to Reproduce:
1. Enter yum update into the terminal as root
2. Get sqlite error
3. Run yum update again, get pidfile error

  
Actual results:
2 separate, repeatable Python tracebacks

Expected results:
My packages get updated

Additional info:
The following is the traceback that appears on the terminal:

$ sudo yum update
<snip>
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 254, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 192, in main
    return_code = base.doTransaction()
  File "/usr/share/yum-cli/cli.py", line 496, in doTransaction
    resultobject = self.runTransaction(cb=cb)
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1175, in runTransaction
    self.history.beg(rpmdbv, using_pkgs, list(self.tsInfo))
  File "/usr/lib/python2.6/site-packages/yum/history.py", line 333, in beg
    yum.misc.getloginuid()))
  File "/usr/lib/python2.6/site-packages/yum/sqlutils.py", line 168, in executeSQLQmark
    return cursor.execute(query, params)
sqlite3.OperationalError: unable to open database file



Subsequent yum updates seem to elicit a different traceback:

$ sudo yum update
Loaded plugins: auto-update-debuginfo, presto
Could not create lock at /var/run/yum.pid: [Errno 22] Invalid argument: '/var/run/yum.pid' 
Another app is currently holding the yum lock; waiting for it to exit...
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 254, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 103, in main
    show_lock_owner(e.pid, logger)
  File "/usr/share/yum-cli/utils.py", line 106, in show_lock_owner
    ps = get_process_info(pid)
  File "/usr/share/yum-cli/utils.py", line 61, in get_process_info
    if (not os.path.exists("/proc/%d/status" % pid) or
TypeError: %d format: a number is required, not str

For the record, there is no /var/run/yum.pid file, and I don't see any packagekit or yum processes in ps before I call yum (I have gnome-packagekit disabled).
Comment 1 James Antill 2010-06-23 01:01:49 EDT
What does the command: ls -l /var/run

...say? I'm suspicious that you might have some FS corruption, if so try rebooting and running fsck.

 To "fix" the history problem you can run: yum history new
Comment 2 Rich Mattes 2010-06-23 01:11:54 EDT
I think you're right.  After I reported this, I went about doing some development, and cmake started throwing errors that it couldn't write to /tmp.  After confirming that I couldn't create any new files in /tmp as any user (even after some generous chmodding) I rebooted and things seemed to start working again (the yum transaction completed, and /tmp was writeable again).

Sorry for the noise.

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