I run darktable 4.4.2 on a System 76 Meerkat, with Pop_OS 22.04. darktable was installed using a flatpack from the Pop!_Shop, and has been updated several times.
darktable and my photo collections are different solid state drives, and I have imported photos edited on another computer, also running Pop_OS 22.04.
Intermittently, when darktable starts, I get the following set of messages:
- Error starting database
- darktable could not be started (database is locked)
- Process ID 2 created the database locks
There is only one instance of darktable running. Restarting the computer does not resolve the situation.
If I select option 3 (delete database lock files to delete data.db.lock and library.db.lock), darktable opens and operates normally.
I have tried:
- Manually deleting data.db.lock and library.db.lock (and their cache copies)
- Uninstalling and reinstalling darktable from Pop!_Shop
- Manually deleting all the darktable files from my home directory, which results in a clean install (i.e., no presets or collections)
When I manually delete everything, darktable works normally for a couple of days. Then I’ll see the “Error starting database” message again, and I’m back to square one.
Any insights and suggestions would be appreciated.
I don’t know much about this, but the database is normally locked when dt starts, then unlocked when it closes, IIRC, to prevent clashes if for instance you accidentally started two instances of dt.
Is dt closing properly? I mean not crashing, or with a hard PC shutdown?
I’m sure others will have more helpful suggestions.
Thanks for the question, Steven.
Yes, darktable is closing normally, and sometimes it restarts normally. Other times, I get the error on restart.
I’ve seen this with the flatpak too, sometimes it just doesn’t exit cleanly. I’m not sure why.
Just delete the lock files and continue on your way
The database files,
library.db are located in your darktable configuration directory. When darktable starts, it creates the corresponding lock files,
library.db.lock. Those are normally removed when darktable exits. If there is a crash preventing the removal, they may be left over; restarting the computer won’t help.
You can find the PID (process ID) of the darktable process that created them by examining their contents:
$ cat data.db.lock
$ cat library.db.lock
If that process is no longer there, it’s safe to delete the lock files.
If darktable continues crashing, it’s worth trying to start it from the console/terminal/command-line and see if there are any error messages.
I have had that error (lockfiles detected) sometimes when restarting darktable too soon after stopping it. Shutdown can take a few seconds…
Thanks for your suggestions, István.
I have triggered the error message, and data.db.lock and library.db.lock are not present in my config file. Both lock files were visible while darktable was running.
In terminal, “cat data.db.lock” returns the message: no such file or directory