Ticket #1661 (closed defect: worksforme)
Opened 7 years ago
Last modified 2 years ago
Database locks after an error involving database with mod_python
| Reported by: | sam | Owned by: | cboos |
|---|---|---|---|
| Priority: | highest | Milestone: | |
| Component: | web frontend/mod_python | Version: | 0.9.4 |
| Severity: | critical | Keywords: | database locked |
| Cc: | sam@…, alexander.neundorf@… | ||
| Release Notes: | |||
| API Changes: | |||
Description
After a Trac Oops error involving a database operation (such as page edition, generally occuring with concurrent page edition), the database is not closed by mod_python. According to cmlenz, it is the expected behavior because of the connection pool.
But what's not expected is that the DB is then locked for a couple of minutes or until Apache is restarted.
Additionnal information
Trac version: trunk/ r1784
Sqlite: 2.8.16-1, from Debian Sid package
Python-sqlite: 1.0.1-2, from Debian Sid package
[Sun Jun 12 14:26:06 2005] [notice] Apache/2.0.54 (Debian GNU/Linux) DAV/2 SVN/1.1.4 mod_python/3.1.3 Python/2.3.5 PHP/4.3.10-15 mod_ssl/2.0.54 OpenSSL/0.9.7g mod_perl/1.999.23 Perl/v5.8.7 configured -- resuming normal operations
Attachments
Change History
comment:1 Changed 7 years ago by cmlenz
comment:2 Changed 6 years ago by cboos
- Keywords database locked added
- Resolution set to worksforme
- Status changed from new to closed
...generally occuring with concurrent page edition
This situation is much better handled now in Trac 0.9
and above, especially when using PySqlite version >= 2.0.5
and SQLite compiled after having set the --enable-threadsafe
configuration switch on Unix/Linux? (the Windows version
being threadsafe by default).
comment:3 Changed 6 years ago by anonymous
- Cc alexander.neundorf@… added
- Priority changed from high to highest
- Resolution worksforme deleted
- Status changed from closed to reopened
- Version changed from devel to 0.9.4
We get the same error. We have installed trac 0.9.4, sqlite 3.3.4 and pysqlite 2.1.3 on a SUSE 9.0. sqlite was compiled with --enable-threadsafe.
Trac is installed as fastcgi with apache 2.
The problem is usually noticed when somebody tries to login to trac.
Oops...
Trac detected an internal error:
database is locked
If you think this really should work and you can reproduce it. Then you should consider to report this problem to the Trac team.
Go to http://trac.edgewall.com/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the python traceback found below.
TracGuide 227 The Trac User and Administration Guide
Python traceback
Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/trac/web/fcgi_frontend.py", line 40, in _handler
dispatch_request(req.path_info, req, env)
File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 139, in dispatch_request
dispatcher.dispatch(req)
File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 107, in dispatch
resp = chosen_handler.process_request(req)
File "/usr/lib/python2.3/site-packages/trac/web/auth.py", line 82, in process_request
self._do_login(req)
File "/usr/lib/python2.3/site-packages/trac/web/auth.py", line 118, in _do_login
db.commit()
OperationalError: database is locked
comment:4 Changed 6 years ago by cboos
- Owner changed from cmlenz to cboos
- Status changed from reopened to new
Is this still happening?
Are the locks "persistent" (i.e. all subsequent requests fail with this error)
or does this only happen occasionally?
comment:5 Changed 6 years ago by anonymous
Yes, it still happens, but quite seldom.
After this all requests fail.
After stopping apache there are still some trac.fcgi hanging around, which can't be killed normally, but SIGKILL has to be used. Then it works again.
Unfortunately I have no idea how to reproduce it. The one who is the first to get this error probably didn't cause it I think.
comment:6 Changed 6 years ago by alexander.neundorf@…
It just happened again. It appeared when somebody tried to login.
Oops...
Trac detected an internal error:
database is locked
If you think this really should work and you can reproduce it. Then you should consider to report this problem to the Trac team.
Go to http://trac.edgewall.com/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the python traceback found below.
TracGuide The Trac User and Administration Guide
Python traceback
Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/trac/web/fcgi_frontend.py", line 40, in _handler
dispatch_request(req.path_info, req, env)
File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 139, in dispatch_request
dispatcher.dispatch(req)
File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 107, in dispatch
resp = chosen_handler.process_request(req)
File "/usr/lib/python2.3/site-packages/trac/web/auth.py", line 82, in process_request
self._do_login(req)
File "/usr/lib/python2.3/site-packages/trac/web/auth.py", line 118, in _do_login
db.commit()
OperationalError?: database is locked
comment:7 Changed 6 years ago by cboos
alexander, the usual question: what SQLite and PySqlite versions are you using?
It looks like you're using the trunk version of Trac. What revision exactly?
comment:8 Changed 5 years ago by cboos
- Resolution set to worksforme
- Status changed from new to closed
I'm going to close this, as we lack detailed information; if someone still experience locks that persist and requires a server restart, please provide us with all the detailed information we need.
We believe that with the recent versions of SQLite and PySqlite, there are no more persistent locks. Transient OperationalError: database is locked are unfortunately quite common (see #3446 and #3503).
comment:9 Changed 2 years ago by siccegge@…
Hm seems something like that is regularlyh happening for me at http://vamos1.informatik.uni-erlangen.de/trac/linux which is Ubuntu karmic's setup of trac with trac-git deployed via mod_wsgi



BTW: This does not happen with SQLite 3.