Bug 429201

Summary: Cannot create sqlite database on mounted CIFS filesystem
Product: [Fedora] Fedora Reporter: Patrick Monnerat <patrick>
Component: createrepoAssignee: James Antill <james.antill>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8CC: james.antill, lmacken
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-21 18:10:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Patrick Monnerat 2008-01-17 21:56:35 UTC
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 13:17:34 UTC
Cannot reproduce (createrepo-0.4.11-2.fc8).
What does Samba log about that problem?


Comment 2 Patrick Monnerat 2008-03-13 14:14:02 UTC
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 21:21:18 UTC
> 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 17:59:54 UTC
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 18:10:08 UTC
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 18:20:50 UTC
Right ! But I think createrepo should at least monitor this error to issue a 
clean message rather than relying on a python stack dump !