Keepassxc: Starting keepassxc doesn't choose the last database though option is ticked

[piedrok]

When I choose the setting "load last database at start" and restart the program, I always get asked to choose a database anyway - the option does nothing it seems...

I suggest the option to be removed (if not working anyway) or to be fixed.

Context

I use gnome on arch and I want to start keepassxc once a session and then leave it in the background.
I do not want to change my local database and asking which database to use is ust a chance for making mistakes...

Your Environment

• KeePassXC version/commit used: KeePassXC - Version 2.1.3
• Qt version (e.g. Qt 5.3): 5.8
• Compiler (e.g. Clang++3.6.0):
• Operating System and version: Arch latest

[mkasberg]

I'm using KeePassXC 2.1.3 on Ubuntu 16.10 and that option works great for me.

The setting is stored at ~/.config/keepassxc/keepassxc.ini. Does KeePass have access to that location on your system?

[louib]

@piedrok can you try with the latest version of the develop branch, which will show a warning message if there is any problem with the config file's permissions (since https://github.com/keepassxreboot/keepassxc/pull/391)?

[meisanerd]

Also, have you closed KeePassXC manually once since opening the file? It appears to save the last database on program close, but on my system, when shutting down the computer, it would sometimes close Keepass before it could save the last database to the config file. Manually closing it resolved the issue.

[louib]

@meisanerd good catch! If that's the case, maybe it's just a matter of manually calling sync() when editing the settings!

[phoerious]

I have suspected something like that for a while, because it just doesn't make any sense that some settings are saved and some are not. We have the same problem when running with ASAN memory leak checks and they report some errors at program exit.

[QQQNo]

I was having the same problem. Linux Mint, first tried with the AppImage, then went for the debian installer. The problem was that the .config/keepassxc/keepassxc.ini was owned by root. KeePassXC was unable to write to it, and it stored only a few settings. Changing the owner to my user with sudo chown USERNAME solved the issue.

[piedrok]

The setting is stored at ~/.config/keepassxc/keepassxc.ini. Does KeePass have access to that location on your system?

I checked and I have full access as user.

Settings are correct in the ini file.

Shutting down keepassxc manually and starting it again works fine.

So obviously when shutting down the system keepassxc seems to miss remembering the last database.

Can't this be solved easily?

Thx to all of you looking into that,
p.

[ghost]

Same problem for me on macOS:

KeePassXC version/commit used:

• KeePassXC - Version 2.1.4
• Qt version: 5.8.0
• Revision: cb283bb95ae559d044415f426f841c27bff383f0
• OS: macOS Sierra Version 10.12.4

If I close KeePassXC with "Datenbank" -> "Beenden" (Database -> Quit (?)), everything is fine: LastOpenedDatabases=/Users/uwe/Eigene Dateien/KeePass/Database.kdbx

But mostly I use the menu "KeePassXC" -> "Quit KeePassXC", because this has the common shortcut "Command Q". With this option, the database can't be remembered:
LastOpenedDatabases=@Invalid()

Perhaps I could manually change the keyboard shortcut (don't know how), but the problem should be solved for everyone.

Greetings, Uwe

[TheZ3ro]

@uwemannl Thanks for the report! I will look into it

[droidmonkey]

Does "KeePassXC" -> "Quit KeePassXC" equate to using the task bar icon? I am not sure where that menu option is that you highlight (screenshot would be great).

[ghost]

@droidmonkey
Sry, I don't understand your first question. I never use the task bar icon under macOS to quit an application.

Here are some sreenshots:

Good behavior / database is remembered:

Bad behavior / entry in config is LastOpenedDatabases=@Invalid():

Also bad:

PS: My macOS is set to german language.

[phoerious]

Qt on Mac does a little magic to match the platform standards. Quit is probably the same as clicking the x button on the window while "Beenden" is our explicit quit menu entry. In the English version, I think Qt automatically detects that our "Quit" entry is a quit command, but in other languages it doesn't and then adds a quit entry on its own. So you end up with two entries, one implicit with "bad" behavior and one explicit (translated) with "good" behavior. This particular thing may actually already be fixed in develop by the patch where we assigned menu roles (not sure, though if we assigned one for Quit). But the general problem of unclean shutdown remains, of course.

@uwemannl can you try changing the language to English and see if you still have two quit entries with differing behavior?

[phoerious]

Actually, yes. We also set a menu role for Quit, so on develop there shouldn't be any duplicate Quit entries anymore (see #483). But if you end the program by any means provided by the OS (window X, quit from the taskbar etc.), the shutdown bug remains, of course. I suppose we are missing a flush call for forcing config writes upon receiving a SIGINT (and whatever the equivalent is on Windows).

[phoerious]

P.S. 2: I need to test if the bug also occurs on Linux. I would assume it doesn't since I wrote a patch for catching SIGINT and SIGTERM on Linux quite some time ago, but it has never been ported to Windows or macOS. The patch was actually for asking the user to save his work instead of just quitting and removing lock files after receiving a termination signal, but it should also flush config changes.

[phoerious]

My SIGINT trap patch was actually also applied to macOS, but closing via dock right click->Quit was a little special, because it sent the close event twice. I submitted a patch (see link above) to ignore the second close event. This should completely resolve this problem on macOS.

Windows still needs a little love, though. My patch also contains a basic implementation for Windows, but it's not yet working.

[piedrok]

Thanks a lot for your efforts and the attention to detail!

Really appreciated and on Arch linux, I just tested once more, - the last databank is remembered again flawlessly. Thx again, p.

[phoerious]

You're welcome. My experience is that it indeed is the details that make the difference whether a program gets your job done or rather on your nerves. ;-)