r/Ubuntu • u/Deepwithin777 • 7h ago

Screen saver triggers KeePassxc to lock database

/r/KeePass/comments/1x5lbr4/screen_saver_triggers_keepassxc_to_lock_database/

Re-posting this to the Ubuntu forum. Interesting what the Brave AI mentioned about KDE/Plasma.

Anything I can tweak in Ubuntu/Gnome ?

2 Upvotes

100% Upvoted

3 comments sorted by

1

u/Deepwithin777 7h ago

See https://github.com/keepassxreboot/keepassxc/issues/6493 ; closed, assuming it was a Gnome problem. Which it most likey is.

1

u/Deepwithin777 7h ago

Here are the results from Brave. Sounds plausible. Which workaround should I try ?

---

screen saver triggers keepassxc lock ubuntu/gnome as cause ?

Quick Answer

The cause is that KeePassXC on Linux/GNOME typically monitors the session idle state (via D-Bus signals like org.gnome.ScreenSaver) rather than the specific "screen lock" event. On many Ubuntu/GNOME configurations, the session is considered idle or the screensaver state changes when the screen blanks, triggering KeePassXC to lock the database immediately.

This creates a conflict when users set the "Blank Screen" delay to be shorter than the "Automatic Screen Lock" delay. Because KeePassXC reacts to the blank/idle signal rather than the actual password prompt appearing, it locks the database prematurely.

To resolve this, users often:

  • Set the Blank Screen delay in GNOME settings to Never or a value longer than the lock delay.
  • Use external tools like xss-lock or custom scripts to decouple the screensaver/blanking event from the session lock signal.
  • Switch to a desktop environment like KDE Plasma, which handles these events more distinctly, or use a different password manager that respects the actual lock screen state.

Copy

+16

elaborate

Researched KeePassXC screen lock behavior

How KeePassXC Detects Lock on Linux

KeePassXC's ScreenLockListenerDBus.cpp watches two D-Bus signals:

Signal Bus What it means
org.freedesktop.ScreenSaver.ActiveChanged (and org.gnome.ScreenSaver) Session bus Screen saver / blank state changed
org.freedesktop.login1.Session.Lock System bus Session actually locked by logind

On GNOME, the problem is that ActiveChanged fires when the screen blanks, not when the password prompt appears. These are two separate events in GNOME, controlled by different timers:

Timer gsettings key Default
Screen blank delay org.gnome.desktop.session idle-delay 300 s
Lock delay (after blank) org.gnome.desktop.screensaver lock-delay 0 s
Lock enabled? org.gnome.desktop.screensaver lock-enabled true

So when the screen goes dark at 300 s, ActiveChanged fires → KeePassXC locks. The actual session lock (which might be 300 + 300 = 600 s later) is a separate event that KeePassXC also listens for, but it's already too late.

The "Cancelled Fade" Bug

There's an additional GNOME bug where the lock signal is emitted as soon as the fade-out animation starts, even if you move the mouse and cancel the lock. So KeePassXC locks even though you never actually left your seat.

Workarounds

1. Use KeePassXC's own inactivity timer instead

Disable "Lock databases when session is locked or lid is closed" (Tools → Settings → Security) and set a fixed inactivity timeout (e.g. 600 s). This is the simplest fix but locks based on KeePassXC inactivity, not system-wide idle.

2. Adjust GNOME blank/lock delays

# Never blank (keeps screen on, defeats the purpose)
gsettings set org.gnome.desktop.session idle-delay 0

# Or: blank at 10 min, lock 0 s after blank (so blank == lock)
gsettings set org.gnome.desktop.session idle-delay 600
gsettings set org.gnome.desktop.screensaver lock-delay 0

Setting lock-delay to 0 makes the lock happen at the same moment as the blank, so the two events coincide and the behaviour is at least consistent.

3. D-Bus script for precise control

You can bypass the built-in listener and drive locking manually via D-Bus:

# Lock
dbus-send --session --print-reply \
  --dest=org.keepassxc.KeePassXC.MainWindow /keepassxc \
  org.keepassxc.KeePassXC.MainWindow.lockAllDatabases

# Unlock (password from gnome-keyring via secret-tool)
tmp_passwd=$(secret-tool lookup keepass mydb)
dbus-send --session --print-reply \
  --dest=org.keepassxc.KeePassXC.MainWindow /keepassxc \
  org.keepassxc.KeePassXC.MainWindow.openDatabase \
  string:/path/to/mydb.kdbx string:$tmp_passwd

Pair this with a dbus-monitor watcher on org.gnome.ScreenSaver to auto-unlock when the session unlocks (see the grabski.me guide).

4. On MATE / other DEs

The relevant key is org.mate.desktop.session idle-delay (not the screensaver setting, despite the GUI placement). A user on Linux Mint forums confirmed that raising this to 43200 s (12 h) stopped the premature lock.

Status

This is a known, open issue (#6493). The KeePassXC maintainers acknowledge it but consider changing the behaviour a security regression (locking earlier than the actual lock is "safer"). No fix is planned — the workarounds above are the current options.