Ticket #8551 (closed defect: worksforme)
Opened 3 years ago
Last modified 18 months ago
OperationalError: unable to open database file
| Reported by: | admin | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | general | Version: | 0.11.1 |
| Severity: | normal | Keywords: | |
| Cc: | |||
| Release Notes: | |||
| API Changes: | |||
Description
How to Reproduce
While doing a GET operation on /, Trac issued an internal error.
(please provide additional details here)
User Agent was: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.39 Safari/530.5
System Information
| Trac | 0.11.1 |
| Python | 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] |
| setuptools | 0.6c8 |
| SQLite | 3.3.4 |
| pysqlite | 2.3.2 |
| Genshi | 0.5.1 |
| mod_python | 3.3.1 |
| Subversion | 1.5.1 (r32289) |
| RPC | 1.0.6 |
| jQuery: | 1.2.6 |
Python Traceback
Traceback (most recent call last):
File "C:\TOW\Python\Lib\site-packages\trac\web\main.py", line 423, in _dispatch_request
dispatcher.dispatch(req)
File "C:\TOW\Python\Lib\site-packages\trac\web\main.py", line 173, in dispatch
chosen_handler)
File "C:\TOW\Python\Lib\site-packages\trac\web\main.py", line 286, in _pre_process_request
chosen_handler = filter_.pre_process_request(req, chosen_handler)
File "C:\TOW\Python\Lib\site-packages\trac\versioncontrol\api.py", line 86, in pre_process_request
self.get_repository(req.authname).sync()
File "C:\TOW\Python\Lib\site-packages\trac\versioncontrol\cache.py", line 89, in sync
','.join(["'%s'" % key for key in CACHE_METADATA_KEYS]))
File "C:\TOW\Python\Lib\site-packages\trac\db\util.py", line 51, in execute
return self.cursor.execute(sql)
File "C:\TOW\Python\Lib\site-packages\trac\db\sqlite_backend.py", line 58, in execute
args or [])
File "C:\TOW\Python\Lib\site-packages\trac\db\sqlite_backend.py", line 50, in _rollback_on_error
return function(self, *args, **kwargs)
OperationalError: unable to open database file
Attachments
Change History
comment:1 follow-up: ↓ 2 Changed 2 years ago by osimons
comment:2 in reply to: ↑ 1 Changed 2 years ago by cboos
- Resolution set to worksforme
- Status changed from new to closed
Replying to osimons:
... I'm tending towards a 'worksforme' with 'look into server-tuning' as general advice.
Ok, that's quite reassuring! Thanks for analysing the issue.
comment:3 Changed 18 months ago by gopalkrao3@…
Hi,
I am getting this error just by browsing to my repository. Originally, I got an error when I was trying to do "SVN Commit" from the "Windows Explorer" using the TortoiseSVC.
Can some one help resolve this issue? I need to submit my changes.
Thanks
Gopal
Changed 18 months ago by gopalkrao3@…
Attached file contains the screen capture of the error screen.
comment:4 follow-up: ↓ 5 Changed 18 months ago by gopalkrao3@…
- Resolution worksforme deleted
- Status changed from closed to reopened
Hi,
After searching the net, I found that when the server (where SVN is running) has run out of disk-space, one would get the error "Can’t find a temporary directory: Internal error". This is the error I get when I am using the TortoiseSVN when I try to commit the changes.
When I try to open the repository on the web I get the error "OperationalError?: unable to open database file".
I request a quicker resolution to this problem as I would like to check-in my changes.
Regards
Gopal
comment:5 in reply to: ↑ 4 Changed 18 months ago by rblank
- Resolution set to worksforme
- Status changed from reopened to closed
Replying to gopalkrao3@…:
I request a quicker resolution to this problem as I would like to check-in my changes.
And you expect... what exactly? That we buy you a new disk? I suggest you talk to your IT staff about that.
Still an InstallationIssue.



While experimenting with some heavy-duty 'Reload All Tabs' with Firefox cache disabled (thread on #8468), I'm quite capable of triggering this error on a regular basis. After much checking and experimentation, I think the issue boils down to the user/process maximum number of open files set by the operating system.
My OSX has a default of 256 open files (file handles?) per process, and every now and then in my logs it also came up as unable to open files like .css files as request by browser. Enable cache in Firefox again, and all pages loads fine (as less files are needed to be opened and transmitted ~simultaneously).
The above error report is from Windows, and I think 'standard' Windows (ie. ~XP) has a default maximum setting of 512 open files per user (not process). Seeing there likely won't be the kind of debug information needed to verify and compare counts of open files (and reasons for being open), I'm tending towards a 'worksforme' with 'look into server-tuning' as general advice.