Fossil crashing on commit with 'database is locked error'
(1) By Premjeet Singh (premjeetsinghhora) on 2019-01-24 13:47:38 [source]
I am new to fossil. I am trying to explore fossil but not able to get it working properly. I am using latest version 2.7 for Windows.
The problem I am facing is that fossil server is crashing very frequently giving 'database is locked error'. At first instance I thought that I am using the server and cloned copy on same system so it might be crashing due to this reason. But when I have started server on another system and even committing to it from a different system the result is same, It got crashed again.
Here is the error it is throwing
D:\Fossil>fossil server Project1.fossil
Temporary files: C:\Users\WIN.USER1\AppData\Local\Temp\2\fossil_server_P8080*
Listening for HTTP requests on TCP port 8080
Type Ctrl-C to stop the HTTP server
backoffice process 7752 still running after 61 seconds
backoffice process 7752 still running after 122 seconds
Database error: database is locked: {INSERT INTO rcvfrom(uid, mtime, nonce, ipad
dr)VALUES(1, julianday('now'), 'f6be3d078c6d91a87290a9ff61aa20d0dd2001d1', '172.
17.20.41')}
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Database error: database is locked: {COMMIT}
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Can you please let me know how to get this resolved?
(2) By Richard Hipp (drh) on 2019-01-24 13:54:06 in reply to 1 [link] [source]
I think this problem may be resolved with the latest trunk version of Fossil. Can you download the source code and recompile, and see if that clears the issue?
(3) By Warren Young (wyoung) on 2019-01-24 14:42:46 in reply to 1 [link] [source]
I am using the server and cloned copy on same system so it might be crashing due to this reason.
That's definitely a great way to get DB locked errors. When the development checkout and the server are on the same system, you generally want to clone from the server even though that means two near-identical copies of the same repo on the same system simply because this greatly simplifies the locking involved. This advice goes double on Windows, which has ridiculously aggressive locking by default.
backoffice process 7752 still running after 61 seconds
Since the backoffice is currently only used for sending alert emails, and setting up email alerts is not something you're likely to do in a situation like yours, if I read it correctly, I'd suggest that you just disable it in the Admin → Settings UI.
(4) By anonymous on 2019-01-24 15:31:39 in reply to 1 [link] [source]
Just an idea: Isn't the reason this error?
I think the latest compiled fossil for Windows is still at the same version as when mentioned first.