Bug 163431 - _sqlite.OperationalError: database is locked
_sqlite.OperationalError: database is locked
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-16 06:25 EDT by Fehér János
Modified: 2014-01-21 17:52 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-29 14:59:03 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 Fehér János 2005-07-16 06:25:11 EDT
Description of problem:

I've tried to upgrade 15 of our workstations from FC3 to FC4. The nodes are
using a central yum cache via NFS. While the upgrading some of them had to be
aborted. They give the error msg on the bottom. Some of them has finished the
upgrade "successfully" but they do the same. Some of them (3) is ok.

I've tried to delete __db.* from /var/lib/rpm , but it wasn't help.

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

rpm-4.4.1-21
rpm-python-4.4.1-21
yum-2.3.2-7
sqlite-3.1.2-3
python-2.4.1-2
python-sqlite-1.1.6-1
python-urlgrabber-2.9.6-1

Steps to Reproduce:
1. Upgrade from FC3 latest to FC4
2. Abort the upgrade
  
Actual results:

Repository extras already added, not adding again
Setting up Upgrade Process
Setting up repositories
livna                     100% |=========================|  951 B    00:00
updates-released          100% |=========================|  951 B    00:00
base                      100% |=========================| 1.1 kB    00:00
extras                    100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
Traceback (most recent call last):
  File "/usr/bin/yum", line 15, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 72, in main
    result, resultmsgs = do()
  File "/usr/share/yum-cli/cli.py", line 428, in doCommands
    return self.updatePkgs()
  File "/usr/share/yum-cli/cli.py", line 877, in updatePkgs
    self.doRepoSetup()
  File "/usr/share/yum-cli/cli.py", line 78, in doRepoSetup
    self.doSackSetup(thisrepo=thisrepo)
  File "__init__.py", line 241, in doSackSetup
  File "repos.py", line 283, in populateSack
  File "sqlitecache.py", line 96, in getPrimary
  File "sqlitecache.py", line 83, in _getbase
  File "sqlitecache.py", line 79, in getDatabase
  File "sqlitecache.py", line 239, in makeSqliteCacheFile
  File "sqlitecache.py", line 150, in createTablesPrimary
  File "sqlitecache.py", line 188, in createDbInfo
  File
"/usr/src/build/539311-i386/install//usr/lib/python2.4/site-packages/sqlite/main.py",
line 244, in execute
_sqlite.OperationalError: database is locked


Expected results:

An upgrade-ed system.

Additional info: rpm, yum are fresh, installed from the central repository.
Comment 1 Seth Vidal 2005-07-16 09:49:16 EDT
the yum cache on nfs is where the problem is. You've got multiple clients
accessing the same sqlite db via nfs and at least one of them is locking the db
for a while.

That's the problem.

Comment 2 Fehér János 2005-07-18 04:04:08 EDT
The problem is permanent, it's still exists since 2 weeks. Only one client
access the cache at the same time. If a client were upgraded successfully, they
can be again without problem.
Comment 3 Seth Vidal 2005-07-22 11:59:26 EDT
right - b/c nfs locking of sqlite dbs is pretty much not going to work.
The resolution to this bug, most likely, is "don't do that"
Comment 4 Fehér János 2005-07-24 05:52:19 EDT
Seth drove me to a workaround:

1) copy the whole NFS repo to the disk of the machine which needs upgrading
2) then yum upgrade

It's not too admin friendly, but works.
Comment 5 Seth Vidal 2005-07-29 14:59:03 EDT
or just setup a local repo in nfs and use it from there.

either way - closing - wontfix

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