bbland wrote: > I have a Trac server that has recently been upgraded by our admins from > 10.0 to 10.0.3. We have a couple of Trac environments using separate > svn repositories. For one environment we aren't having any problems. > For the other we can't even log in anymore. Here's the response from a > login attempt: > > Traceback (most recent call last): > File "/usr/local/trac/lib/python2.4/site-packages/trac/web/main.py", > line 387, in dispatch_request > dispatcher.dispatch(req) > File "/usr/local/trac/lib/python2.4/site-packages/trac/web/main.py", > line 237, in dispatch > resp = chosen_handler.process_request(req) > File "/usr/local/trac/lib/python2.4/site-packages/trac/web/auth.py", > line 100, in process_request > self._do_login(req) > File "/usr/local/trac/lib/python2.4/site-packages/trac/web/auth.py", > line 141, in _do_login > db.commit() > OperationalError: database is locked > > I've poured through postings and bugs and it seems killing all of the > processes that might be involved with Trac clears up problems like this > most of the time. Since I don't have direct control over them I asked > our admins to just reboot the machine. They've since done this and the > problem is still there. Does anyone have any tips? I'm at a loss as > to where to look for a persistent lock. > > Setup: > Sqlite 3.3.7 > Python 2.2.2 > Apache (don't know the version) > We're also using an LDAP plug-in for authentication > > - Brock
I had some luck deleting rows (maybe all of them) from the 'session' table. That was to fix the issue temporarily. Permanently, the fix has been to move to Postgresql. BA --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
