Opened 20 years ago
Last modified 18 years ago
#571 closed defect
trac locks database and causes potential corruption when using apache on windows — at Version 22
| Reported by: | anonymous | Owned by: | Jonas Borgström |
|---|---|---|---|
| Priority: | highest | Milestone: | |
| Component: | general | Version: | 0.8 |
| Severity: | critical | Keywords: | svn database lock |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description (last modified by )
Here's the description from one of our developers…
Trac is causing Subversion database corruption and I had to disable it. Even though Trac only reads database, every read operation locks it, like it's going to do transaction. That doesn't jive well with normal svn client that uses svn_dav Apache module to access database. In the end, two different access methods cause DB corruption (we didn't lose anything with nightly backup and incremental dump on commit). I don't expect to re-activate Trac soon (soon=weeks or months).
Change History (22)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
| Keywords: | lock added; corruption removed |
|---|
More comments… It's not that causes corruption, it's that locks the database and never exists. Apache is running on Windows 2000 server (svn repository is on same box). We noticed that when lock happens happens we have multiple python.exe processes running. Worst of all nothing can kill these processes and we have to reboot server.
comment:3 by , 20 years ago
I've saw this twice with trac 0.6.x, also under Apache / Win2K Server - locked Subversion, multiple Python processes hung up on the server. Although it may purely be coincidence, I haven't had an issue since upgrading to 0.7.x.
comment:4 by , 20 years ago
I ran into this two times the last week. Running svnadmin recover solved the problem the first time, but i disabled trac when it happened again.
Is this a trac or svn-problem?
comment:7 by , 20 years ago
| Milestone: | 0.7.1 → 0.7.2 |
|---|
comment:8 by , 20 years ago
I've completely disabled trac here, too. It's not only related to windows as it seems to be implied. Indeed I run trac on a 'debian stable'
comment:9 by , 20 years ago
After some testing and experimenting i've came to the following conclusion: This is probably NOT a trac/svn-problem! It is probably just a permission error on the svn db.
We had problem with several people writing to the repository using file:///, but when wo put them all in the svn grop and chmodded the db directory g+s that problem solved. I thought this might apply to trac too, so I tried it and guess what? Adding the apache-user to the svn group has resulted in no more lockups so far.
comment:10 by , 20 years ago
And you think this will help us on Windows platform? Permission setting is well known issue/solution on Linux/Unix systems. We are all talking about Windows servers here.
comment:11 by , 20 years ago
www-data is in the svn group, and the repository permission are set according to subversion recommendations (g+s)… and I had (and still have) locks from time to time.
comment:12 by , 20 years ago
We are running trac and apache here. The primary problem we encountered was setting permissions up correctly, but since trac runs as the apache user we have no problem with concurrent access between trac and apache.
It is useful to set your directories as g+s, but you must also set a umask of 002 or similar for every process accessing those directories via group access, since DB4 will create new files periodically. If this happens with a umask of 022, the process which caused the creation will exit cleanly, but the next process to attempt to read the database via group permissions will cause DB4 to lock the database and complain loudly about a lack of permissions.
We here now have a umask of 002 set for the apache process, which neatly covers both davsvn and trac access.
— bje
comment:13 by , 20 years ago
Thanks. Nice explanation. Too bad it doesn't cover Windows platform, since there are no umask and g+s there.
comment:14 by , 20 years ago
| Summary: | trac locks database and causes potential corruption when using apache → trac locks database and causes potential corruption when using apache on windows |
|---|
It appears this issue has been boiled down to a windows-only issue at this point. The reality here is that its most likely a fault in the svn/python support, but until this is confirmed this ticket can remain open.
comment:17 by , 20 years ago
I had this problem quite a bit with SVN & ViewCVS (which also uses the python bindings, but after upgrading the python bindings to 1.0.6 I have only had one lockup in 3 weeks where I used to them almost daily before.
Please check your python bindings and upgrade - it may solve your problems too!
comment:18 by , 20 years ago
We have been running Trac 0.7.1 on a Windows XP machine for over a month here and got a few lock ups. It is believed that they occur after the server is shutdown and restarted.
I had to go through the SVN documented procedure to unlock it:
http://svnbook.red-bean.com/svnbook-1.0/apb.html#svn-ap-b-sect-1.2.1
This operation always succeeded so far. Hopefully, it will continue to succeed.
Now, is this related to the issue described in this ticket? I do not know.
comment:19 by , 20 years ago
This subversion issue should be fixed in subversion 1.1, especially when using FSFS.
comment:21 by , 19 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:22 by , 19 years ago
| Description: | modified (diff) |
|---|---|
| Resolution: | fixed |
| Status: | closed → reopened |
Don't close as anonymous or without a comment.
This sounds like a Subversion bug, not a Trac bug. Nothing that Trac should be able to do should cause DB corruption.
Although it may help with the changes to access the repository via the RA interface rather than the filesystem one.