Keepassxc: Shutdown signal is handled incorrectly

[LinuxOnTheDesktop]

Expected Behavior

My computer should shut down when I tell it to / KeePassXC should handle shutdown signals in the right way.

Current Behavior

Attempt to shutdown the computer graphically fails when KeePassXC is running and a database has been opened but is not visible. (Will KeePassXC prevent shutdown in other situations? I don't know; more testing is needed - but see this closed bug report: #2692.)

Possible Solution

Steps to Reproduce

1. Install KeePassXC snap on Mint Cinnamon 19.1 x64.
2. Open a KeePassXC database.
3. Minimise KeePassXC to the tray/panel.
4. Try to shutdown the computer via some (any) GUI. (Using the terminal may work properly.)

Context

It makes KeePassXC unworkable, forcing me back to KeePass-under-mono. Using the latter is involved, a bit slow, poorly themed and works badly with clipboard managers. Moreover, the whole point of KeeePassXC is to avoid such kludges on Linux.

Debug Info

KeePassXC - Version 2.4.3
Revision: 5d6ef0c
Distribution: Snap

Qt 5.9.5
Debugging mode is disabled.

Operating system: Ubuntu Core 18
CPU architecture: x86_64
Kernel: linux 5.2.3-050203-generic

Enabled extensions:

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

Cryptographic libraries:
libgcrypt 1.8.1

Operating system: Mint 19.1 Cinnamon
CPU architecture: amd 64
Kernel: 5.2.3 (but I had the problem on older kernels too)

Enabled extensions:

• See above.

[phoerious]

This sounds like #2692 to me.

[droidmonkey]

As discussed before this is not critical, there is a workaround. Simply exit KeePassXC prior to shutting down. How often are you restarting anyway?

[LinuxOnTheDesktop]

How often are you restarting anyway?

Frequently. For (1) it's a laptop, (2) it a laptop afflicted with a still unsolved-for-some-models bug whereby deep seep does not work, and (3) my testing of some other malfunctioning software requires some extra restarts.

@phoerious

This sounds like #2692 to me.
Yes. I cited that report. That report is closed; the (/a) dev wanted a new bug report. So here it is.

[bipox]

As discussed before this is not critical, there is a workaround. Simply exit KeePassXC prior to shutting down. How often are you restarting anyway?

I am restarting my computer multiple times a day.

Believe me, this tiny extra step gets annoying after a thousand times.

In my case (KDE Neon), if I forget to close KeePassXC first the whole shutdown through GUI won't work anymore, and I have to use the terminal.

[droidmonkey]

pkill keepassxc && shutdown -r

Script on the desktop, run to restart... Until this is fixed

[LinuxOnTheDesktop]

Script on the desktop, run to restart... Until this is fixed

I am running KeePass (through Mono) until this is fixed.

Moreover: thanks for trying to help, droidmonkey, but I wish this bug report to be about data gathering and fixing the problem.

[droidmonkey]

Can anyone point me to the documentation for KDE, XFCE, GNOME, etc. that shows what signal is emitted when a shutdown is requested? To fix this issue we need to distinguish between a "close" event from the user and a "close request" event from shutting down. Otherwise it is impossible to know whether to hide to the tray or actually quit the application.

[LinuxOnTheDesktop]

I can provide a little for Cinnamon, namely, the following.

1. There is some documentation here, but I am unsure any of it is relevant.
2. The Cinnamon github repo is here.
3. Mint's email address (though in my experience no-one ever answers this mail): root [at] linuxmint [fullstop] c-o-m [without the dashes]. There is another address too, which is the same as the first one, except that 'root' is replaced by 'admin'.
4. The Mint dev's IRC is #linuxmint-dev. I am unsure I've ever seen anyone there, though. (All in all, Mint does not make it easy to get in touch.)

[phoerious]

This is definitely a regression, most likely from when we "fixed" the hide-to-tray feature. Perhaps we need to hook onto logind's DBus signals.

[andreas-p]

This happens on MacOS as well. Shutdown will get interrupted unless KeepassXC is quitted manually before.

[LinuxOnTheDesktop]

Judging by this and the other bug report (the latter being linked above), the problem occurs in all of the following environments: Cinnamon; Gnome; KDE; MacOS. That suggests in turn that the problem is not with all of those environments but with KeePassXC itself.

[droidmonkey]

This might be as easy as this: https://www.qtcentre.org/threads/33320-Break-system-shutdown-when-in-my-program-I-want-minimize-instead-close?s=699f0c96e7c23cd31c6317348d1c1daa&p=154353#post154353

[the-nic]

is there a fix prepared? will it reach 2.5.0?

[the-nic]

according to https://github.com/telegramdesktop/tdesktop/issues/633, they're just checking if QGuiApplication::isSavingSession() is true during closeEvent() and if so, they quit

[droidmonkey]

Forgot about this, will add tonight and test

[LinuxOnTheDesktop]

This issue may need re-opening. Here is why.

Starting after I installed KeePassXC (which I did on the understanding that the shutdown problem was finally fixed), sometimes there is an interval of approximately thirty seconds between (1) my telling my laptop to shutdown and (2) the shutdown procedure starting in any visible way. On the latest occasion that this happened, I notice that my panel showed the KeePassXC application was running and/but clicking the KeePassXC icon on that panel did nothing.

It is possible that something other than KeePassXC causes these intermittent shutdown delays. I find it very hard to determine what stalls shutdown at the desktop stage (as against once the GUI is down).

I can at least provide the following information - and, later, I will try to record, and add here, just when the shutdown stall (and it is a stall, which is better than a total abort)

KeePassXC
Version: 2.5.0
How installed: PPA

Relevant KeePassXC settings
Start only a single instance: yes
Minimise window at app start: yes
Minimise window after unlocking database: no
Backup database file before saving: yes
Auto save after every change: yes
Hide window when copying to clipboard: minimize
Minimize instead of app exit: yes
Show a systemtray icon: yes

Database stored on a folder synced by Syncthing. Syncthing seems to be working correctly.

Relevant system specifications (erring on the side of over-providing)
OS: Linux Mint 19.2 Tina x86_64
Host: 20KHCTO1WW ThinkPad X1 Carbon 6th
Kernel: 5.3.7-050307-generic
Uptime: 5 mins
Packages: 3035 (dpkg), 15 (flatpak), 4 (snap)
Shell: bash 4.4.20
Resolution: 2560x1440 @ 60.01Hz
DE: Cinnamon 4.2.4
WM: Mutter (Muffin)
WM Theme: N_cinn (Mint-Y-Dark-BB_hack)
Theme: Mint-Y-Dark [GTK2/3]
Icons: Paper [GTK2/3]
Terminal: xfce4-terminal
Terminal Font: InconsolataGo 12
CPU: Intel i7-8550U (8) @ 4.000GHz
GPU: Intel UHD Graphics 620
Memory: 1925MiB / 15907MiB
Disk (/dev/nvme0n1p4): 19G / 40G (49%)
Disk (/dev/nvme0n1p2): 184G / 405G (48%)
Disk (udev): 0 / 7.8G (0%)

[phoerious]

Are you using KeePassXC from a remote file system or is your database particularly large? In any case, that would be a different issue, most likely.

[LinuxOnTheDesktop]

@phoerious: no (not a remote file system) and no (database is not especially large).

[andreas-p]

On MacOS 10.14.6, the KeepassXC 2.5 window will come up when I try to shutdown the machine, but the system will blame Keepass for preventing the shutdown.

[LinuxOnTheDesktop]

This bug should be re-opened, I believe - at least if it is fixed in neither the most recent ppa version nor the appImage.

On one of my Linux machines, the problem - I think it is a KeePassXC problem (it is hard to tell) - delays leaving the desktop by some fifteen seconds. I have KeePass 2.5.1 on my computers.

[droidmonkey]

This issue is corrected and there is nothing further that we can do to placate stubborn desktop environments.

[LinuxOnTheDesktop]

So, you have warranted confidence that all the problems in this area are on the DE's side and not yours? If so: does the history of the bug support that view?

[droidmonkey]

Unless a reliable replication environment can be setup, then yes. What you described (delay of 15 seconds) is entirely different then the previous behavior (complete block of shutdown).

[LinuxOnTheDesktop]

Thanks for the response.

Unless a reliable replication environment can be setup, then yes.

I take it that you mean: unless and until 'a reliable replication environment can be setup', it is reasonable to believe that any problems in this area are not the fault of KeePassXC. But why? Why does lack of reproducibility entail that the DE is to blame? Still, I appreciate that the modular nature of Linux - and with different people maintaining the different bits, and a great variety in some of the bits - makes matters hard.

What you described (delay of 15 seconds) is entirely different then the previous behavior (complete block of shutdown).

Entirely? Shutdown is at issue in both problems. But I would be happy enough to open a separate issue.

[droidmonkey]

Are all your machines setup the same? You also stated it was hard to tell if this was KeePassXC at all. I'm just going by your additional report details. If 1 out of X machines behaves strangely it is incredibly difficult to fix.

[LinuxOnTheDesktop]

I have three machines with KeePassXC: (1) a Thinkpad X1 with Linux Mint; (2) a Thinkpad X230 with Linux Mint; (3) a Dell T1650 with Windows 10. I don't have the problem of 3. I do have it on 1. I can't remember whether I've had it on 2. (I don't use 2 very much.) After Christmas I can do some testing on 2.

The reason I suspect KeePassXC is to blame, is that, as this issue (ticket) attests, KeePassXC had problems in this area - and I've installed nothing new that seems a likely culprit on 1.

Shall we just leave this open - or I'll open another issue and we'll leave that open - to see whether anyone else has the problem?

[andreas-p]

Problem still present under MacOS as well. I have quite some other apps that stay open permanently (several messaging apps) that catch the close button to minimize instead, and it's only KeepassXC that inhibits shutdown.

[droidmonkey]

If you open a new issue make sure to include 100% details to replicate. OS version, deaktop env, etc.

[andreas-p]

New for MacOS as issue #4057