"Database error: database is locked" problem
(1) By jvdh (veedeehjay) on 2019-01-31 14:01:05 [link] [source]
5 minutes ago I encountered this error (for the first time after a couple of years with fossil):
Database error: database is locked: {REPLACE INTO vvar VALUES('ci-comment',some_text.')}
when trying to checkin a change. the autosync against the server completed but after being directed to my editor, entering the checkin comment and leaving the editor I got the above error.
I worked around it by closing and re-opening the local repo but would appreciate advice, why and how this error can occur (notably, as far as I can tell I definitely was not in the middle of a checkin in another window/shell which might have caused the lock)
(2) By sean (jungleboogie) on 2019-01-31 15:22:56 in reply to 1 [link] [source]
See a similar post:
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.
(3) By jvdh (veedeehjay) on 2019-02-01 07:15:13 in reply to 2 [link] [source]
thanks for the pointer, but this seems not to be quite the same situation:
in my case the remote repo was another machine (serviing the repo via the cgi approach).
also, my assumption was, that the LOCK was/is a local problem, especially so, since it went away after closing/reopening the local repo, no?
since I forgot in my original mail:
This is fossil version 2.8 [103997d96e] 2019-01-11 05:34:07 UTC
running on the local OSX machine. the remote serve says
This is fossil version 2.6 [27e5e5ce65] 2018-06-26 11:21:08 UTC
any more ideas?
(4) By anonymous on 2019-02-01 15:04:35 in reply to 1 [link] [source]
> when trying to checkin a change. the autosync against the server > completed but after being directed to my editor, entering the checkin > comment and leaving the editor I got the above error. Did you by chance have the "fossil ui" or "fossil server" running in the background on your local machine?
(5) By jvdh (veedeehjay) on 2019-02-01 15:26:34 in reply to 4 [link] [source]
in fact, yes, "fossil ui" might have been running in the background at that time... mmh.
does this really lock the database regularly and prevent checkins?? if so, I must have been lucky to not having encountered this before...
or what exactly is the problem?
in any case thanks for pointing this out. I will try to remember that the reason for such a lock seemingly could be a running instance of "fossil ui".
(6) By Martin Gagnon (mgagnon) on 2019-02-01 16:31:52 in reply to 5 [link] [source]
Should be no problem if "fossil ui" is just running and nobody access it.
/timeline?n=all on an big repo) and close your editor at the same moment ? (I'm just guessing)
(7) By jvdh (veedeehjay) on 2019-02-01 16:45:15 in reply to 6 [link] [source]
I cannot completely rule out the first possibility: editor opened and switching to another virtual screen on my desktop where the webinterface might have been running. so maybe I accidentally "interacted" with the webinterface and then went back to the editor window. if that could produce such a LOCK, ok...I will make a memo and check this when I get around to it.
(8) By Richard Hipp (drh) on 2019-02-01 17:02:58 in reply to 5 [link] [source]
It should not be a "problem".
On the other hand, you shouldn't ever get "database locked" errors. The fact that you do is a bug. If I could reproduce the issue, I would try to fix it.
I think the suggestion about a concurrent "fossil ui" was more speculation about what might be causing the problem, and should not be interpreted as a warning against doing that. You ought to be able to have multiple "fossil ui" commands running while trying to check-in and still not get "database locked" errors.
If you do come up with a way to reliably reproduce this issue, please let me know.
(9) By jvdh (veedeehjay) on 2019-02-01 17:07:21 in reply to 8 [source]
good, understood.
if I encounter the error again, I will try to find a way to reproduce it (given that I have seen this error for the first time only after several years of using fossil the chances might be low, though...)
(10) By Martin Gagnon (mgagnon) on 2019-02-01 17:35:19 in reply to 8 [link] [source]
I just find a way to reproduce a similar error, not sure if it's what happens with the OP.
Here's my step to reproduce. (it is a bit timing critical)
1- Have some change to commit on any repository, and run "fossil commit" to start the external editor.
2- Put some comment and save, be prepared to close the editor quick on next step (but don't close it now)
3- On another terminal window, execute "fossil up", and before it finish, close the editor window.
After closing the editor, you should get the following error from "fossil commit":
fossil: database is locked: {REPLACE INTO vvar VALUES('ci-comment','bla.')}
If you let the "fossil up" finish without closing the editor window, fossil up will give an error after a short timeout:
fossil: database is locked: {COMMIT}
(11) By Warren Young (wyoung) on 2019-02-01 19:23:17 in reply to 8 [link] [source]
you shouldn't ever get "database locked" errors. The fact that you do is a bug.
To be clear, are you only talking about the case where the background Fossil instance isn't actually modifying the DB at the same time?
It's my understanding that trying to use the same repo file for both "fossil server" and the checkout where you're running "fossil ci" is always going to lock up like this because both the client and server are in the middle of a transaction during the sync. Since both SQLite instances are using the same DB file to modify the same tables, and they're both in the middle of a nontrivial transaction, it's always going to get stuck.
Ultimately, I want to know if my advice to work from a clone when also running "fossil server" on the same machine and checking back into that same repo is valid.
It appears that's not what's happening here, but if running Fossil as a client and server on the same repo at the same time is also supposed to work, I've definitely seen that lock up in the past. I haven't seen it lately because I now always work from clones even on the Fossil server.
(12) By anonymous on 2019-02-03 06:51:30 in reply to 8 [link] [source]
> I think the suggestion about a concurrent "fossil ui" was more speculation about what might be causing the problem
It was indeed an attempt to speculate about the cause of the problem.
Here is a reproducible way of getting a locked error, though I'm not sure it's what the OP did:
1) Make an edit to a file in one terminal (perhaps in tmux)
2) Type fossil commit to bring up the commit editor
3) Navigate to a different terminal (perhaps switch panes in tmux)
4) cd to the same working directory where the edit has occurred and run fossil status; note that it still shows a file as EDITED
5) Proceed to run a second fossil commit in this new terminal
6) Get an error about the database being locked
Example:
xterm 1$ export EDITOR=ed
xterm 1$ fossil commit
ed "./ci-comment-AD405BB5BC3E.txt"
129
xterm 2$ export EDITOR=ed
xterm 2$ fossil status
repository: /tmp/new/../new.fossil
local-root: /tmp/new/
config-db: /home/joe/.fossil
checkout: 291a092bdb238cecbce97e2639085c0448e3c402 2019-02-03 06:38:52 UTC
parent: 269c5328a4e3fcbc5135dd1d7c5c27e3d75174d6 2019-02-03 06:38:34 UTC
tags: trunk
comment: go (user: joe)
EDITED file
[NOTE: there is some unexpected delay before getting the next prompt]
xterm 2$ fossil ci
ed "./ci-comment-E8E608F13EA5.txt"
129
i
This is a test.
.
w
145
q
Database error: database is locked: {COMMIT}
Again there was some odd delay after entering q and receiving the database error.
Is this perhaps what the OP did?
(13) By Warren Young (wyoung) on 2019-02-03 07:31:36 in reply to 12 [link] [source]
I'm pretty sure that's a feature. Here are the alternatives, as I see them:
Allow two commits atop the same parent, creating a fork that you then have to manually heal.
Put off starting the commit transaction until the commit message editor exits, then fail the commit if the parent isn't a leaf checkin any more, requiring that you do a "fossil up" and then reattempt the checkin.
Fast-forward the second checkin to the new tip of the branch without consulting the user first, thus risking an unwanted rollback, a merge conflict, or a broken checkin.
Are you seeing a fourth option, or do you think one of those three is better than the current behavior?
(14) By jvdh (veedeehjay) on 2019-02-03 08:25:22 in reply to 12 [link] [source]
OP here. no, that is not what I did. the error message is different, too. in my case it was
Database error: database is locked: {REPLACE INTO vvar VALUES('ci-comment',some_text.')}
actually this is the same message mgagnon could trigger (see elsewhere in this thread) by trying a checkin during a still running 'fossil up'. but I believe that also was not what happened to me (I wouldn't do that knowingly at least ..))
(15) By Richard Hipp (drh) on 2019-02-04 16:18:24 in reply to 1 [link] [source]
I just now encountered this error myself. I was doing a commit, and while typing in the lengthy check-in comment, I brought up a "fossil diff --tk" from a separate terminal window to make sure I hadn't missed any changes. I don't recall if I saved my check-in comment first and then shut down the "fossil diff --tk" command, or if I shutdown the "fossil diff --tk" command first. But after I was done, I noticed that the commit did not take, and have given me the database locked error while trying to do
REPLACE INTO vvar VALUES('ci-comment','...')
(16) By jvdh (veedeehjay) on 2019-02-04 16:57:47 in reply to 15 [link] [source]
good to know that you can confirm it. actually, I might (just might..) have done the same, namely look at a diff in a different window. if so, quite probably using gdiff with some graphical merge/diff tool, but definitely not diff --tik (if tha'ts of any relevance to the issue)