Client hangs indefinitely at startup (no window) when the system keyring / Secret Service is unresponsive

[OlivierMary]

Description

On Linux, the desktop client can hang indefinitely at startup. The kDrive server process starts, logs up to Prepare Parms DB, and then never launches the GUI: no window, no tray icon, no kDrive_client process, and nothing more is written to the log.

The root cause is that, during startup, the client performs a synchronous libsecret call — secret_password_store_sync() — on the main/GUI thread, with no timeout. If the system Secret Service (org.freedesktop.secrets, typically gnome-keyring) is present but does not answer the request, the whole startup blocks forever.

gdb backtrace of the frozen main thread:

#0  __poll (timeout=-1)
#1  g_main_context_iterate     (libglib-2.0)
#2  g_main_loop_run            (libglib-2.0)
#3  secret_password_storev_sync (libsecret-1)
#4  secret_password_store_sync  (libsecret-1)
#5  ... (kDrive server startup)
    main

This looks like it may be the same root cause behind several existing "starts but no window/tray ever appears" reports (e.g. #1631, #1063, and similar threads on the openSUSE / Ubuntu forums).

Steps to reproduce

Any state where the Secret Service accepts the D-Bus connection but does not answer Store/prompt requests triggers it. The common real-world trigger is a stale/corrupted gnome-keyring after an OS upgrade (in my case Linux Mint 21 → 22, i.e. Ubuntu 22.04 → 24.04 base): org.freedesktop.secrets is registered, but the default login collection is in an inconsistent state.

Quick way to tell the keyring is in that broken state (this hangs):

python3 -c "import secretstorage as s; c=s.get_default_collection(s.dbus_init()); c.create_item('t', {}, b'x')"

Minimal deterministic reproducer with a mock Secret Service that owns the name but never answers OpenSession:

# mock_secret_service.py
import dbus, dbus.service
from dbus.mainloop.glib import DBusGMainLoop
from gi.repository import GLib
DBusGMainLoop(set_as_default=True)
class Service(dbus.service.Object):
    @dbus.service.method('org.freedesktop.Secret.Service',
                         in_signature='sv', out_signature='vo',
                         async_callbacks=('cb', 'eb'))
    def OpenSession(self, algo, inp, cb, eb):
        pass  # accept the call, never reply
    @dbus.service.method('org.freedesktop.DBus.Properties',
                         in_signature='ss', out_signature='v')
    def Get(self, iface, prop):
        return dbus.Array([], signature='o') if prop == 'Collections' else dbus.String('')
bus = dbus.SessionBus()
dbus.service.BusName('org.freedesktop.secrets', bus)
Service(bus, '/org/freedesktop/secrets')
GLib.MainLoop().run()

eval "$(dbus-launch --sh-syntax)"     # isolated private session bus
python3 mock_secret_service.py &
./kDrive-x.y.z-amd64.AppImage          # hangs at "Prepare Parms DB", no window ever appears

Expected behavior

The client should never block its GUI thread on the system keyring. It should:

• use the asynchronous libsecret API (secret_password_store) or wrap the call with a timeout;
• surface an error ("Cannot access the system keyring") instead of freezing silently;
• log the keyring step — currently nothing is logged between Prepare Parms DB and the freeze, which makes this extremely hard to diagnose.

Screenshots
N/A — no window is ever shown.

Logs
The server log stops here and nothing follows while frozen:

[I] db.cpp:397 - Prepare Parms DB

Additional context

• Environment: Linux Mint 22 (Ubuntu 24.04 base), X11 / Cinnamon, kDrive 3.8.x AppImage. Also verified identical behaviour on 3.7.x and 3.8.1 AppImages, so this is not a recent regression.
• Workaround for affected users: restart the keyring daemon and start the client again —
  gnome-keyring-daemon --replace --daemonize --components=secrets (a reboot fixes it too). The client then starts normally.
• Note: running the AppImage as fake-root (unshare -r ...) also appears to "work", but only because the keyring call fails fast as root instead of blocking — it is not a real fix and it breaks the OAuth browser login.