Opened 18 years ago
Closed 18 years ago
#5159 closed defect (fixed)
trac-admin resync on project with empty repos renders project inaccessible
Reported by: | Owned by: | Christian Boos | |
---|---|---|---|
Priority: | normal | Milestone: | 0.10.4 |
Component: | version control | Version: | devel |
Severity: | blocker | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Upgrading from 0.10.3 to 0.10.4rc1, a number of our projects turned out to be inaccessible - traceback with the usual database is locked
error message. And, they were really locked - restarting Apache did not help. Even tried a reboot without success.
After a number of hours of research tonight I have identified when it occurs, and how to fix it: It occurs when running trac-admin resync
on a project that has an empty Subversion repository - no changesets. Doing the resync leaves an extra trac.db-journal
file in the project db folder, and by deleting the file the project is accessible again.
The project(s) will be inaccessible through OSX/Apache 2.2/mod_python 3.3.1/Python 2.4.3 in my test, but also inaccessible through the Python interpreter when using _open_environment()
- for some reason likely related to common caching/pooling:
from trac.env import Environment; myenv = Environment('/path/to/problem/env') # Works from trac.web.main import _open_environment; myenv = _open_environment('/path/to/problem/env') # Does not work (database locked)
As before, running resync on projects with empty repositories should not be able to render the project inaccessible. However, 'why' (and 'where' in code) this happens I have to leave to others - my hunch is 'version control' and 'caching', but cannot really tell.
As far as I can tell, this has to be a show-stopper for 0.10.4 - at least I will set the ticket properties to reflect this. Do change if I am mistaken!
Attachments (0)
Change History (4)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
Owner: | changed from | to
---|---|
Version: | devel → 0.5.1 |
comment:3 by , 18 years ago
Owner: | changed from | to
---|---|
Version: | 0.5.1 → devel |
Please don't do what looks like random changes for fun or test. Resetting fields.
comment:4 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Ok, I reproduced the issue. The presence of the journal shouldn't block other processes; this can however happen if the journal is still held open. So it all depends on how trac-admin is run:
- in interactive mode, there are pending changes and the journal is kept open, preventing other processes to access the db. This is most probably what happened for you.
- in batch mode, those pending changes are left in the journal, but as the process is terminating without committing or rolling back the changes, the journal file stays but will get removed by the next process attempting to use the db (assuming it has the permission to remove that file)
Of course, what needs to be done is to actually commit those pending changes. In normal circumstances a commit will be done (there is one after each changeset is synced). For an empty repository, there's nothing sync and hence no commit of the eventual metadata changes.
Thanks for the report, and yes, this is a blocker issue. I hope it won't delay the 0.10.4 release though, if I manage to fix the issue this evening.
Possibly related tickets: #4937, #5080, #5048