Darktable won't start



Darktable does not start properly on my machine. To be precise: It starts immediately only once after booting. If I have closed it I will always be presented the error-message that the lockfiles contain a prog-ID that belongs to a running instance of DT when I start it again. Deleting the lock-files does not change anything.

I know this should have been fixed in 2.2, but it is not. I have this issue with 2.2.5-2 and the git-version.

OS: Antergos
Kernel: x86_64 Linux 4.13.11-1-ARCH
DE: KDE 5.40.0 / Plasma 5.11.3
CPU: Intel Core i5-2500K @ 4x 3.7GHz [69.5°C]
GPU: AMD BARTS (DRM 2.50.0 / 4.13.11-1-ARCH, LLVM 5.0.0)
RAM: 2837MiB / 7958MiB

I have ~84.000 files from my server in the database.

Any hint appreciated.

Oh, and I can’t for the life of me get opencl to work with the radeon-driver for my HD 6850. But that is a different topic I guess.


(Mica) #2

If you use the CLI and pass a new db location, will it open?


Yes. It also starts when I rename my old library and let it create a new one.



Please show a screenshot of the error message.


I’ll use XNViewMP for that. Much quicker. :slight_smile:



So when closing that dialog and deleting /home/mic/.config/darktable/*.lock (there are two lock files!) you still can’t start dt?
The fact that you are seeing that dialog at all indicates that dt is crashing during shutdown, before it can clear the lock files. Do you have any backtraces in /tmp/darktable_bt_*?


No backtraces there.



Just noticed that if I just wait for some time - probably 3,4 minutes - simply ignoring the error-message and not deleting any lock-files DT will finally start.

Makes me think it has something to do with
a) the amount of images (various raw/jpg/tif/png) - +84.000
b) the images being stored on a server



That makes no sense. Is your home directory on some unusual file system? Network share, overlay fs, …?


No. It is on a local btrfs-formatted SSD.
The files are on a Ubuntu-Server (HP Proliant) in a gigabit-net.



@houz Might he have more than instance open?



No. Definitely not.



Next thing to test:

  • close darktable
  • check with ps/top/… if it’s really closed. Maybe something is slow there?

If that doesn’t answer it we probably have to use strace.


Obviously DT is trying to access each and every file of the +84.000 on the server before it even thinks about starting its GUI. According to strace. And the CIFS-mounted shares are available.

On a second look DT is actually looking for files that do not exist at all - .wav and .txt.


stat("/mnt/srv_foto_wrk/Foto_DIV/balgenkamera.jpg.xmp", {st_mode=S_IFREG|0755, st_size=1232, …}) = 0
access("/mnt/srv_foto_wrk/Foto_DIV/balgenkamera.txt", F_OK) = -1 ENOENT (No such file or directory)
access("/mnt/srv_foto_wrk/Foto_DIV/balgenkamera.TXT", F_OK) = -1 ENOENT (No such file or directory)
access("/mnt/srv_foto_wrk/Foto_DIV/balgenkamera.wav", F_OK) = -1 ENOENT (No such file or directory)
access("/mnt/srv_foto_wrk/Foto_DIV/balgenkamera.WAV", F_OK) = -1 ENOENT (No such file or directory)



That’s fine, it’s the crawler. But that has nothing to do with the error about lock files. Those are checked before the crawler runs.


Dunno. Fact is: When I disable the crawler (by GUI-setting or editing darktable.cfg) I can start and stop DT as often as I want without any hassle. No error-message, no zombie-process. All okay.



On a final note.

I decided to give up on DT as a tool to manage my pretty large collection of digital assets. I am using Digikam for this now and will keep DT for what it without doubt does best: (RAW-)Processing.