Keepassxc: KeePassXC stops shutdown on some Linux distributions

[LinuxOnTheDesktop]

After KeePassXC beta is loaded at boot, shutting the system down (/restarting it) does not work the first time, unless one issues a shutdown command from terminal. Or at least I suspect that KeePassXC is involved in the causation of this problem.

Expected Behavior

When I tell the machine to shutdown (or restart) it should do so.

Current Behavior

Possible Solution

Steps to Reproduce

1. Set KeePassXC-2.4.0-beta1-x86_64.AppImage to run on boot.
2. Boot.
3. Shutdown or restart.

Context

I am on Mint 19.1 Cinnamon and Cinnamon does have a lot of bugs.

Debug Info

KeePassXC - Version 2.4.0-beta1
Build Type: PreRelease
Revision: 42cfe01
Distribution: AppImage

Libraries:

• Qt 5.10.1
• libgcrypt 1.8.1

Operating system: Linux Mint x64 19.1 Cinnamon
CPU architecture: x86_64
Kernel: linux 4.20.7-042007-generic

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (only unsigned sharing)
• YubiKey

I did try to discuss this on IRC but there was no-one there the two times I tried it.

[droidmonkey]

You may have already done this, but I have to ask...

Have you tried removing KeePassXC and rebooting to see if the issue persists?
Disabling the on-boot load of KeePassXC, simply run the appimage, and see if the issue persists?

[LinuxOnTheDesktop]

I was and still am testing whether removing the appimage - and running instead only the installed version - removes the problem. (When I used the installed version exclusively I did not, I think, have the problem. But, if I do encounter the problem now - whilst I have running the installed version but not the appimage - then I will disable the installed version and see whether the problem persists in that scenario.)

[droidmonkey]

I cannot replicate this on Ubuntu 18.04 running Gnome.

[LinuxOnTheDesktop]

@droidmonkey
Thank you for trying. If you _can_ replicate it on Mint Cinnamon, then I know where to point the finger.

[LinuxOnTheDesktop]

My problem with shutdown disappeared when I stopped using the beta appimage. So, probably: either the beta itself is causing the problem or else something to do with Mint's handing of appimages is causing the problem.

[LinuxOnTheDesktop]

I should like to note that this problem is rather serious, at least when there are long periods between releases. For, the appImage problem means I (and others?) cannot use betas. And I wanted to use a beta because of bugs in the released version (and I only turned to KeePassXC in the first place because of problems with vanilla - Windows - KeePass, running via Mono). I suppose I could build from source . .

I appreciate that you are volunteers, but, really, this is no fun at all, at least given the many other 'papercut' bugs of other Linux packages.

[droidmonkey]

This is not serious. You can quit the application before shutting down (aka workaround). It is also not reproducible in other distros.

[LinuxOnTheDesktop]

I note that the problem affects the second beta version as well as the first.

I note also that the problem is somewhat serious, in that (1) using the release version means that sometimes the user must dismiss a password-entry box before entering a password in another box, and (2) if the user uses the beta, then he or she must remember to shutdown KeePassXC before every shutdown, or else try to shutdown, notice it fails, and then close KeePassXC and reinitiate shutdown. And doing either 1 or 2 every day is a considerable pain, if I may say so.

Perhaps the problem is with Mint or with Cinnamon. If so, it would be good to have some pointers as to where more exactly to seek the problem / point the finger.

[droidmonkey]

OK, I have the time to test this now. I loaded Mint 19.1 with cinnamon in VirtualBox.

2.3.4 AppImage -> enabled systray icon, minized to systray, restart without an issue (immediate)

2.4.0-beta2 AppImage -> same settings, restart without an issue (immediate)

Both versions I had a database opened at the time of restart (no pending save).

I tried 2.4.0-beta2 again while editing an entry with unsaved changes. Restart was blocked with KPXC minimizing to systray. Issuing a second restart worked.

2.4.0-beta2 -> unsaved database while visible, restart blocked
2.4.0-beta2 -> unsaved database while minimized to systray, restarted immediately

[LinuxOnTheDesktop]

Thanks, droidmonkey. So, it the cause (proximate cause, anyway) something in the appimage format or something in a code change between the beta and the release version? Also, does the problem have anything to do with a signals problem mentioned (I believe) in reports upon the first beta?

[droidmonkey]

To me this is really a bug in cinnamon. It is aborting the restart/shutdown sequence for some reason even though we are not explicitly blocking it. I think when kpxc is visible and minimizes to tray then cinnamon gives up shutting down because it is assuming we are asking to save changes or whatever.

[LinuxOnTheDesktop]

Thanks. If - and only if - someone supplies me with more details, then I will be able to file a bug report against Cinnamon. It would be pretty bad were this problem to persist into the release version of KeePassXC.

[phoerious]

I saw this once on KDE with 2.4. I have not seen it since, so I don't know how to reproduce it.

[vip9]

It supress reboot/halt on Plasma. After closing keepassxc, KDE is still unable to reboot/shutdown.

KeePassXC 2.4.0, compiled from sources.

Operating System: Kubuntu 18.10
KDE Plasma Version: 5.15.3
KDE Frameworks Version: 5.54.0
Qt Version: 5.11.1
Kernel Version: 4.18.0-16-generic
OS Type: 64-bit

[PlqnK]

Because my issue was a duplicate of this one, I'm reposting my debug info here:
KeePassXC - Version 2.4.0
Revision: c51752d

Libraries:

• Qt 5.12.2
• libgcrypt 1.8.4

Operating system: Arch Linux
CPU architecture: x86_64
Kernel: linux 5.0.3-arch1-1-ARCH

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (only unsigned sharing)
• YubiKey

Desktop Environment:

• KDE Plasma 5.15.3
• KDE Frameworks 5.56.0

As said in the other issue it has something to do with Minimize instead of app exit option because after disabling it the problem goes away.

To be more clear about what the problem is; when KeePassXC is running with the option Minimize instead of app exit enabled and I try to log out I get a notification from Plasma Workspace saying Logout canceled by '/usr/bin/keepassxc', same happens if I try to reboot or shutdown the computer from Plasma interface.

Workarounds are:

• Disabling the option named Minimize instead of app exit in KeePassXC settings.
• Manually closing KeePassXC before logging out/rebooting/shutting down.

[LinuxOnTheDesktop]

I feel this problem - which I raised at the beta stage - should have prevented the release of 2.4. Note that implementing either of the workarounds (well, at least the first one) will encourage the user to learn a habit that s/he will have to unlearn once the problem is fixed. Still, it's not my decision. For my part, I'm going back to the previous version.

[phoerious]

This issue is not always reproducible and needs some more investigation. The 2.4 release has been stalled long enough.

[PlqnK]

I have a 100% reproducible way if you need:

1. Download KDE Neon User Edition ISO
2. Boot it in a VM
3. Add your ppa to the repolist and update the repolist
4. Install KeePassXC
5. Launch KeePassXC, you don't need to create or open a database
6. In the settings, check Minimize instead of app exit
7. Try to log out from KDE Plasma application launcher

[phoerious]

It's very peculiar, because we fixed exactly this problem in 2.3. Hard to believe its back. Need to find the responsible commit I guess.

[finderAUT]

Can also confirm the bug on Fedora 29 (with Gnome 3.30.2) when "Minimize instead of app exit" is enabled.

KeePassXC - Version 2.4.0

Libraries:

• Qt 5.11.3
• libgcrypt 1.8.4

Operating system: Fedora 29 (Workstation Edition)
CPU architecture: x86_64
Kernel: linux 5.0.4-200.fc29.x86_64

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (only unsigned sharing)
• YubiKey

[LinuxOnTheDesktop]

There is reason to believe that this bug is worse than it was thought to be. For, on Mint, it seems that KeePassXC 2.4 stalls shutdown (for some twenty seconds) even when Minimize instead of app exit is disabled. All that is necessary for the stall is having KeePassXC running. But perhaps I misunderstood the proposed workaround. Perhaps the proposed workaround intends that one ensure that KeePassXC is not running when one shuts down, with the disabling of the option being merely a means to that.

[LinuxOnTheDesktop]

I can add that KeePass _2.3.1_ seems to cause the problem, on Mint 19.1 Cinnamon, too. I do not think that used to happen with KeePass 2.3.1. Strange.

[droidmonkey]

My humble opinion is that this is really an issue at the desktop environment level. We do not issue any signal that should be construed as "STOP SHUTDOWN". There are probably many other applications that cause hangs in the restart/shutdown process inadvertently. The fact of the matter is that the desktop environment should provide a reasonable grace period, then either force terminate or ask the user if they want to force terminate. This is exactly what Windows does and it works very well. We can maybe fix this by being smarter about how to handle event messages from X11, but honestly it really is not unique to our application.

[LinuxOnTheDesktop]

I can vouch that Cinnamon will stall or even abort the shutdown of the desktop environment at the drop of a hat. Or at least a few programs have caused such problems (and that's even before we get to the _whole system shutdown_ and the problems systemd causes with that). Still, by 'stall' I mean 'wait twenty seconds and then shutdown' and that is indeed what Cinnamon does (sometimes . .) when there is a problem. It is what it did when I had the problems with KeePass 2.4.1. Once I reverted to 2.3.1, though, Cinnamon began simply to _abort_ shutdown if KeePassXC was running. But even twenty seconds - at least when the system gives one no explanation (and you have to hunt in and decipher the logs) - is too long; so I've had to go back to (mono) KeePass.

The biggest problem here, I think, is fragmentation. For, it seems that a fix would be forthcoming only if KeePassXC people were to work with the DE devs.

[joanbm]

I also stumbled upon what seems to be the same problem. I use Arch Linux with i3, and I launch from the i3 configuration something like cat /secret/password | keepassxc --pw-stdin at startup.

In my case, I get to the point where systemd sends the termination signals to the remaining processes, and it looks like KeePassXC doesn't stop (sometimes), so I get the 1 minute 30 second user session timeout from systemd until it kills the process.

This is a shutdown log I got from systemd:

[  111.113148] systemd-journald[340]: Journal effective settings seal=no compress=yes compress_threshold_bytes=512B
[  119.862727] systemd[1]: session-1.scope: Stopping timed out. Killing.
[  119.862988] systemd[1]: session-1.scope: Killing process 801 (keepassxc) with signal SIGKILL.
[  119.863009] systemd-journald[340]: Journal effective settings seal=no compress=yes compress_threshold_bytes=512B
[  119.863261] systemd[1]: session-1.scope changed stop-sigterm -> stop-sigkill

Debug Info

KeePassXC - Version 2.4.1
Revision: 7bafe65

Qt 5.12.2
Debugging mode is disabled.

Operating system: Arch Linux
CPU architecture: x86_64
Kernel: linux 5.0.7-arch1-1-ARCH

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (signed and unsigned sharing)
• YubiKey

Cryptographic libraries:
libgcrypt 1.8.4

[joanbm]

I can replicate the systemd timeout delay due to KeePassXC when shutting down 10% of the time (randomly but consistently). However, I have not been able to replicate the problem by sending SIGKTERMs/SIGHUPs through pkill, so I'm not sure what is going on at shutdown time, and it complicates diagnosis. Fastest way I've found is running kexec over and over again so I can quickly reboot with ~15 seconds per reboot.

I tried to add some traces to a log file and the SIGTERM seems to correctly emit the application exit signal and start quitting, but it seems to get stuck at DatabaseTabWidget::closeAllDatabaseTabs for some reason (my traces weren't too robust, so don't quote me on that). I though that probably the signals were handled incorrectly, so I took a look the signal handling code, and it's basically the same thing the Qt documentation recommends, so I'm not sure where the problem could be. I also tried to remove the Qt::DirectConnection argument that the exit signal -> exit event handler code has in case it made any difference, but I could still replicate the problem.

[Bujiraso]

Adding my impact here that I have this 100% of the time, fully reproducible if the Tools -> Settings, -> "Minimize instead of app exit" is selected.
Happens 0% of the time if it's not toggled. Seems to be the keep-alive function that causes the issue.

So, @droidmonkey, am I correct to reword what you said as roughly being 'this happening because the shutdown signal is not being communicated as "final"'? To that end, I agree that forcing a shut-down is something that the desktop environments should all do, but Florian brought up a great point on a related Gnome 3 bug here: https://gitlab.gnome.org/GNOME/gnome-session/issues/18 -- we're not actually there yet, so what if the user accidentally hit the prepare-for-shut-down prompt?
To elaborate a little, please note that in my case, what's happening is that the Gnome 3 user has not even received the true shut-down prompt. They haven't said "Yes" to shutting down. That means the desktop is only optimistically requesting apps to finalize their work and not confirming a shut-down yet, so there's a perhaps bit of nuance hiding here about when things are happening.

A fix to me would be to allow Gnome 3 to give the shut-down prompt -- KeepassXC doesn't need to do anything too fancy -- e.g. auto-save if the user has that configured. It may be that the d-bus messaging is being interrupted or broken, according to my vague understanding from the related Gnome bug. Florian suggested a host file system issue.

Debug Info

KeePassXC - Version 2.4.1
Revision: 7bafe65

Qt 5.12.2
Debugging mode is disabled.

Operating system: Arch Linux
CPU architecture: x86_64
Kernel: linux 5.0.7-arch1-1-ARCH

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (signed and unsigned sharing)
• YubiKey

Cryptographic libraries:
libgcrypt 1.8.4

[droidmonkey]

I do not know what signal is sent on shutdown. Its very straight forward on Windows and Mac. Does gnome send a dbus signal to every app? That is what I understood from the comments in the gnome issue thread. Does systemd send a signal?

Anyway, I think another solution would be to exit the app if a "close" signal is sent while the app is already in the tray. This signal cannot possibly come from the user hitting the X button since the window is not visible.

[Bujiraso]

So it would be Gnome sending a signal to d-bus (to each app, yes) but I'm not a gnome developer, sorry. Please feel free to reach out to Gnome or post on that ticket -- you're more than welcome to, I'm certain.

edit: As mentioned below this seems to affect all major desktop environments (Gnome, KDE, Cinnamon, etc.?), so the issue is general. Just suggesting that Gnome devs on that ticket may have ideas on how to fix it better than I do.

Your other solution sounds very clever. I like it.

[LinuxOnTheDesktop]

Discussants please note that Cinnamon is affected as well as Gnome [EDIT:] and KDE / Plasma.

[LinuxOnTheDesktop]

@ Bujiraso: by my counting, above there are four reports pertaining to KDE. Perhaps I misunderstand something. Certainly I should have said in my comment above, 'Cinnamon is affected as well as Gnome and KDE'. I have edited my comment such that now it _does_ say that.

[Bujiraso]

(shh! don't out me that I didn't CTRL+F hard enough before deleting that ;) )

[ddobrev]

This also happens on macOS 10.14. When I shut down, nothing happens and instead the main window of KeePassXC activates (comes to the foreground). When I quit KeePassXC, then shutting down proceeds.

[ddobrev]

@droidmonkey is perhaps shutting down on macOS a separate issue? Should I report it as such?

[droidmonkey]

Probably not. I don't have the bandwidth to chase down platform specific bugs right now. Esoteric issues like these are very time consuming to fix and are not guaranteed to work.

With that said i can and will implement my suggested "fix" above.

[bssb]

I believe this is the commit that caused the issue:

https://github.com/keepassxreboot/keepassxc/commit/a44138dd5c4b1c0f28f127140de0836d4999f144#diff-eadbad473622c6ca681370585fb4d9e4

Specifically, in MainWindow::closeEvent(), event->accept() was replaced with event->ignore().

I'm running KDE on Arch, and reverting that one line fixed it for me. I've created a PR, #3150, if anyone has time to help test it I would appreciate it. Thanks.

[PlqnK]

Quick question about your fix : If "Minimize instead of app exit" is enabled and you click on the cross to close the window, what happens? Does the program completely quit (no more icon in the tray) or does it only get minimized to the tray?

[bssb]

Before applying the fix, clicking the cross minimizes the window to the KDE task manager, or to the system tray if "show a system tray icon" is enabled. The program stays running. After applying the fix, the behavior is the same except that when the system tray icon is disabled, the window does not get minimized to the task manager (it disappears to the background). However the program stays running, and can be brought to foreground by clicking on the KeePassXC launcher icon. Thank you for pointing that out. So this is a problem, but I'm not sure how it would be fixed.

[droidmonkey]

A proposed fix was merged into 2.4.2 (being release today). I am keeping this issue open so people can test it with their setup to see if the issue persists and under what conditions.

[PlqnK]

2.4.2 already being in the Arch repos means I've been able to test your change!
When Minimize instead of app exit is enabled, it doesn't inhibit a reboot/shut down/log out when minimized to tray anymore. But it still does it when the program is not minimized to tray like in the foreground, background or minimized to the taskbar/dock.

[droidmonkey]

That is intended because the fix was to close the program if it was already in the tray. If it's not in the tray you need to issue two shutdowns (for now).

[LinuxOnTheDesktop]

    I installed the latest Snap version on Linux Mint. I can supply the following data points.

1. I minimised the program to my panel (not my tray, although I told KeePassXC to show a tray icon). Then I restarted my system. The restart worked first time.

2. I minimised KeePassXC to the system tray - not to the panel - and tried to restart. It worked perfectly.

3. I had the main KeePassXC window (the database window) open and tried to restart. It worked perfectly.

    However, the following problems will keep me on KeePass-under-Mono for the time being, even though I appreciate the progress made.

• The KeePassXC tray icon is too close to the other icons; it looked squashed in. I thought I had reported this already but I cannot find the existing bug report. Screenshot:

• The snap version of KeePassXC does not theme properly.

[droidmonkey]

The snap version is still 2.4.1. i had to revert it because of a missing library. We have no control over the display of the tray icon, I have absolutely no clue what is going on there.

[finderAUT]

Didn't have time to test it as long as it was in testing but updated today as 2.4.2 got added to stable for Fedora 30.

Ticket should be reopened as it still does not work.

Window gets minimized when initiating shutdown but window to choose cancel, reboot, shutdown does not get displayed. If it is already minimized nothing happens.
Did not test with tray.

[droidmonkey]

@finderAUT as my comment above mentions... the fix is not total. I would rather open a new issue that specifically addresses listening for shutdown signals on Linux. That is the only way to solve this problem. Unfortunately that will take a lot of effort to figure out.

[finderAUT]

Sorry, you are right that would definitely be better.
Because even if I set it to minimize to tray it does not work because it just does not get minimized to tray (I guess because GNOME does not support it anymore, although it was still possible in Fedora 29)

[joanbm]

As a workaround to avoid a systemd 90 second timeout, I have been running for months a patched version of KeePassXC with the registerUnixSignals(); code line commented. However, after 2.5.2 came out, I decided to check if this issue was fixed in the official version, and I can no longer replicate it. I don't know what changed, whether KeePassXC, Qt, systemd or something else, but the problem I had doesn't happen anymore.

EDIT: Downgrading to 2.4.3 made the problem reappear. So it looks like the fix was in KeePassXC.

[droidmonkey]

sweet!