Fossil Forum


Fossil: database is locked

By nocom on 2018-09-20 02:14:13 [link]

I am new to fossil. I installed fossil on ubuntu 18. Tried to init my first project "fossil init test" and got the message; "fossil: database is locked". Rebooted, tried again and got the same message. What exactly is wrong here?

By jungleboogie on 2018-09-20 03:16:58 [link]

Can you please show the commands and the output you received when you attempted this? What exactly was rebooted? Was this on a read only file system?

By anonymous on 2018-09-20 03:26:58 [link]

Does it show the same error if trying another name for the new repository? Here are some sample steps to try:

mkdir newproj
cd newproj
fossil init ../newproj.fossil
fossil open ../newproj.fossil
echo "this is a test" >newfile.txt
fossil add newfile.txt
fossil status
fossil commit -m "added new file"
fossil timeline

Here's a Quick Start Guide

In case it fails the same, you may need to review how you installed fossil, it's possible it's running some other 'fossil' (any aliases defined?). There could be some permissions issues either in your home or the local directory.

You can try to find what you're running, by executing this at the command line:

which fossil

On Ubuntu, when installed via apt, the fossil binary is usually /usr/bin/fossil. If so, you may run:

fossil version

and let us know what version it reports back.

By anonymous on 2018-09-20 03:28:35 [link]

I encountered similar situation. The prompt likes >database is locked: {INSERT INTO config(name,value,mtime)VALUES('baseurl:http://',1,now())}>

Pull done, sent: 293 received: 356 ip: Autosync failed. continue in spite of sync failure (y/N)?

By wyoung on 2018-09-20 10:58:17 and edited on 2018-09-20 11:00:59 [link]

I think you're running into a different situation than the OP.

Ignoring Windows, a database locked error usually happens when you've got a fossil server instance attached to a Fossil repo file then try to modify that same repo from a checkout directory on the same server:

  $ fossil server x.fossil &
  $ mkdir x
  $ cd x
  $ f open ../x.fossil
  hack hack hack
  $ fossil ci

Unless your repos are huge, a simple solution is to work from a clone even though you've already got a copy of that repo DB on the same server.

Please confirm: are you in fact attempting to share a Fossil repo file in this way?

Windows is a separate ball of mud because of its default mandatory file locking behavior.

It should be possible to allow fossil server and fossil ci to share a single repo file, which would be especially useful when the repo size gets large, but there seems to be little interest in making Fossil cope with this use case.

A simple test case here on a small repo doesn't reproduce the problem, which leads me to believe that this happens due to a timeout being too low to give fossil server time to do what it needs to with the DB before the client gives up trying its locks. That's consistent with the large number of artifacts we see in your posted output.