Startup fails with error message "Another instance of KeePassXC is already running"

[thommierother]

Keepassrc does not start, only shows "Another instance of KeePassXC is already running" although there is no keepassrc process and even no configs in ./config/ (no keepassxcrc etc.)

Expected Behavior

Successful startup

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

Context

Debug Info

Information for package keepassxc:

Repository : Security
Name : keepassxc
Version : 2.2.0-14.2
Arch : x86_64
Vendor : obs://build.opensuse.org/security
Installed Size : 6.8 MiB
Installed : Yes
Status : up-to-date
Source package : keepassxc-2.2.0-14.2.src
Summary : Qt5-based Password Manager

Libraries:

• LIBS

Operating system: OpenSUSE leap 42.2,
CPU architecture: 64 bit
Kernel: 4.4.79-18.26-default
plasmashell 5.8.6

Enabled extensions:

• EXTENSIONS

[bullet64]

In your DB Folder is an .lock File. Remove this File and you can use your DB again.

.DB_name.kdbx.lock

[thommierother]

Hi,
thats what I thought first also, but there is no lock before startup, even no old one:

thommie@locutus:~/Dokumente/Netzwissen/Security> ls -la
insgesamt 460
drwxr-xr-x 2 thommie users 125 24. Aug 09:34 .
drwxr-xr-x 7 thommie users 4096 13. Jul 15:59 ..
-rwxr-xr-x 1 thommie users 1854 11. Jan 2017 locutus_rootca.crt
-rw-r--r-- 1 thommie users 420622 23. Aug 18:17 Thommie2.kdbx

[thommierother]

Any ideas on this? I deleted all possible tmp/cache files but still I get "Another instance of KeePassXC is already running" although there is no other instance in the process list. This makes the application unusable, I have to switch back to keepassx

[RealOrangeOne]

As a short-term solution, if you're 100% sure nothing else is using the file (check running processes too just in case), you can always click Yes in that dialog to get back to using your database. Not ideal, but if youre sure nothing is using it, it's really not that damaging. I do it all the time, as my sync client also syncs the lock file 👍

[phoerious]

These are actually two different mechanisms. The lock file is for making sure you don't accidentally open the same database twice, whereas this mechanism simply implements a single-instance mode. If an instance of KeePassXC is already running, it is brought the foreground instead of starting a new instance.

Checking whether another instance is already running is done via socket connections. So please check if you have any stray keepassxc sockets in your temp folders (usually /tmp).

[thommierother]

Indeed, there was a lock in /tmp and the lock referred to the socket. I deleted it and the issue is fixed.
Thx for the hint. I should have used tmpfs ;-)

[droidmonkey]

This might point to a larger issue that perhaps we need a mechanism in the warning message to say "delete the existing lock and load anyway"

[thommierother]

May just change the message:

old "Another instance of KeePassXC is already running "
new "Another instance of KeePassXC may be running. Please check also for stale lock files"

[phoerious]

I think we just need a check if the process which owns the socket still exists.

[droidmonkey]

Im reopening because this is the root of the issue.

[huffman]

I ran into this same issue on Windows 10. There were no instances of KeepassXC running, and the issue persisted after restarting my computer. Running KeepassXC from the command line (mingw git prompt and cmd.exe) did not show an error. Finally starting the exe from Visual Studio displayed the message "Another instance of KeePassXC is already running." in the log and led me to finding the lock file.

(It sounds like the proper fix is known, I just wanted add another data point. Let me know if there's anything else I can do to help)

[karser]

Fixed keepass by removing both files:

rm /tmp/keepassxc-<user>.lock
rm /tmp/keepassxc-<user>.socket

KeePassXC - Version 2.5.4