Bug 429201 - Cannot create sqlite database on mounted CIFS filesystem
Cannot create sqlite database on mounted CIFS filesystem
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: createrepo (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: James Antill
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-17 16:56 EST by Patrick Monnerat
Modified: 2014-01-21 18:01 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-21 14:10:08 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 Patrick Monnerat 2008-01-17 16:56:35 EST
Description of problem:
Submitting command "createrepo -d" on some directory residing on a CIFS mounted
filesystem crashes.

Version-Release number of selected component (if applicable):
0.4.11-1.fc8

How reproducible:
Always in the conditions mentioned above.

Steps to Reproduce:
1. mount -t cifs //machine/share /mnt -o user=authorized_user
2. copy rpm files to /mnt/somedir/
3. createrepo -d /mnt/somedir
  
Actual results:
.
.
.
Saving Primary metadata
Saving file lists metadata
Saving other metadata

(process:2199): GLib-CRITICAL **: g_timer_stop: assertion `timer != NULL' failed

(process:2199): GLib-CRITICAL **: g_timer_destroy: assertion `timer != NULL' failed
Traceback (most recent call last):
  File "/usr/share/createrepo/genpkgmetadata.py", line 713, in <module>
    main(sys.argv[1:])
  File "/usr/share/createrepo/genpkgmetadata.py", line 637, in main
    mdgen.doRepoMetadata()
  File "/usr/share/createrepo/genpkgmetadata.py", line 316, in doRepoMetadata
    dumpMetadata.repoXML(reporoot, self.cmds)
  File "/usr/share/createrepo/dumpMetadata.py", line 813, in repoXML
    rp.getOtherdata(complete_path, csum)
  File "/usr/lib/python2.5/site-packages/sqlitecachec.py", line 57, in getOtherdata
    self.repoid))
TypeError: Can not create db_info table: database is locked

Expected results:
.
.
.
Saving Primary metadata
Saving file lists metadata
Saving other metadata
$

Additional info:
Can live without "-d" for yum purpose, but this makes repoview'ing the directory
impossible.
Comment 1 Michael Schwendt 2008-03-13 09:17:34 EDT
Cannot reproduce (createrepo-0.4.11-2.fc8).
What does Samba log about that problem?
Comment 2 Patrick Monnerat 2008-03-13 10:14:02 EDT
Nothing !
Samba is configured in ADS security and the R/W mounted share resides on a
W$2003 server. Other operations with this share are OK.
Perhaps I need to configure some additional log options... if so, please help.
Thanks

Note: with createrepo-0.4.11-2.fc8, the error lines have changed:
.
.
.
Traceback (most recent call last):
  File "/usr/share/createrepo/genpkgmetadata.py", line 722, in <module>
    main(sys.argv[1:])
  File "/usr/share/createrepo/genpkgmetadata.py", line 646, in main
    mdgen.doRepoMetadata()
  File "/usr/share/createrepo/genpkgmetadata.py", line 321, in doRepoMetadata
    dumpMetadata.repoXML(reporoot, self.cmds)
  File "/usr/share/createrepo/dumpMetadata.py", line 813, in repoXML
    rp.getOtherdata(complete_path, csum)
  File "/usr/lib/python2.5/site-packages/sqlitecachec.py", line 57, in getOtherdata
    self.repoid))
TypeError: Can not create db_info table: database is locked
Comment 3 Michael Schwendt 2008-03-13 17:21:18 EDT
> the R/W mounted share resides on a W$2003 server

Which may be the crucial detail.
CIFS alone is not enough to reproduce this.

"database is locked" is SQLite's infamous SQLITE_BUSY error
(I don't know what kind of locking mechanism it uses).
Comment 4 Patrick Monnerat 2008-04-21 13:59:54 EDT
You're probably right to say it's an SQLite problem.
I used wireshark to spy the CIFS protocol and noted a lock request answer with 
error code STATUS_LOCK_NOT_GRANTED.
I then tried to fiddle around with mount parameters: the bug does not occur 
anymore when mount option "nobrl" is used. This is not a fix, but at least, 
this workaround allows performing the "createrepo -d" on a CIFS share. I don't 
know what is the real impact of this option on locking efficiency...
Many thanks for your help.
Comment 5 Seth Vidal 2008-04-21 14:10:08 EDT
okay, I'm going to close this notabug - or at least not a createrepo bug. If
you'd like to reassign it to sqlite, you're welcome to.

thanks
Comment 6 Patrick Monnerat 2008-04-21 14:20:50 EDT
Right ! But I think createrepo should at least monitor this error to issue a 
clean message rather than relying on a python stack dump !

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