oo7-daemon 0.7.0.beta: panic at startup in Service::connection() (server/src/service/mod.rs:1283, unwrap on None)

[perceival]

Summary

On every login, oo7-daemon 0.7.0.beta logs a panic in a tokio worker a few milliseconds after startup:

thread 'tokio-rt-worker' (5370) panicked at server/src/service/mod.rs:1283:31:
called `Option::unwrap()` on a `None` value

Line 1283 at tag 0.7.0.beta is Service::connection():

pub fn connection(&self) -> &zbus::Connection {
    self.connection.get().unwrap()
}

so some task spawned during startup calls connection() before the D-Bus connection has been stored.

Timeline (one login, GDM password login via pam_oo7)

09:22:52.457747Z INFO  oo7_daemon: Received login secret from helper
09:22:52.457756Z INFO  oo7_daemon: Starting oo7-daemon
09:22:52.457767Z INFO  oo7_daemon::service: Starting PAM listener
09:22:52.457820Z INFO  oo7_daemon::pam_listener: PAM listener started on /run/user/1000/oo7-pam.sock
         .461316       thread 'tokio-rt-worker' panicked at server/src/service/mod.rs:1283:31  (Option::unwrap() on None)
09:22:52.497205Z INFO  oo7_daemon::service: Unlocked keyring 'login' from ".../keyrings/v1/login.keyring"
09:22:52.497318Z INFO  oo7_daemon::service: Discovered 1 keyring(s), 0 pending migration(s)
09:22:52.497329Z INFO  oo7_daemon::service: Setting up collection 'login' (alias: default).

The panic happens on every boot (seen on 3 consecutive logins). The daemon keeps running and the login keyring still unlocks, so the impact looks limited to whatever the panicking task was supposed to do — but it is reproducible and presumably a startup ordering bug (task spawned before connection is set).

Environment

• Fedora 45, GNOME (Wayland), GDM password login
• oo7-daemon-0.7.0~beta-1.fc45, oo7-portal-0.7.0~beta-1.fc45, pam_oo7-0.7.0~beta-1.fc45 (updates-testing)
• Keyring migrated from gnome-keyring (v1/login.keyring, "0 pending migration(s)")
• gnome-keyring-daemon --components=secrets was also autostarted (it logs "another secret service is running")

I can provide a full RUST_BACKTRACE=1 trace from the next login if useful.

[bilelmoussaoui]

That would be very helpful so we can tell which task has caused the panic

[bilelmoussaoui]

gnome-keyring-daemon --components=secrets was also autostarted (it logs "another secret service is running")

Why you still have that running?

[perceival]

Here's the symbolized trace (installed oo7-daemon-debuginfo, RUST_BACKTRACE=1). The panic is in open_session — an OpenSession call gets dispatched before Service::connection is set:

thread 'tokio-rt-worker' (3474) panicked at server/src/service/mod.rs:1283:31:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic
   3: core::option::unwrap_failed
   4: <oo7_daemon::service::Service>::open_session::{closure#0}::{closure#4}
   5: <oo7_daemon::service::Service as zbus::object_server::interface::Interface>::call::{closure#0}
             at /usr/src/debug/oo7-0.7.0~beta-1.fc45.x86_64/server/src/service/mod.rs:141:10
   6: <oo7_daemon::service::Service as zbus::object_server::interface::Interface>::call::{closure#1}
             at /usr/src/debug/oo7-0.7.0~beta-1.fc45.x86_64/server/src/service/mod.rs:76:1
   7: <zbus::object_server::ObjectServer>::dispatch_call_to_iface::{closure#0}
   8: <tracing::instrument::Instrumented<<zbus::object_server::ObjectServer>::dispatch_method_call_try::{closure#0}::{closure#5}> as core::future::future::Future>::poll
             at /usr/share/cargo/registry/zbus-5.19.0/src/object_server/mod.rs:429:30
   9: tokio::runtime::task::raw::poll::<...>
             at /usr/share/cargo/registry/tokio-1.53.1/src/runtime/task/core.rs:380:24
  10: <tokio::runtime::scheduler::multi_thread::worker::Context>::run_task
  11: tokio::runtime::scheduler::multi_thread::worker::run
  12: tokio::runtime::task::raw::poll::<tokio::runtime::blocking::task::BlockingTask<...>>

Timeline: PAM listener started (12:41:54.5247) → panic (≈12:41:54.53) → Unlocked keyring 'login' (12:41:54.5692). So the object server is already serving org.freedesktop.Secret.Service on the bus before the connection is stored.

Re gnome-keyring: it's still installed on Fedora 45 because NetworkManager-vpnc-gnome requires it. gnome-keyring ships /usr/share/dbus-1/services/org.freedesktop.secrets.service, whereas oo7-daemon ships no D-Bus activation file (it only starts via pam_oo7 / oo7-daemon.service). So any early client D-Bus-activated gnome-keyring and it raced oo7 for org.freedesktop.secrets; when gnome-keyring won, apps (Chrome) hit its un-unlocked legacy keyring and prompted for a password. I've added a per-user activation file (Exec=/usr/libexec/oo7-daemon, SystemdService=oo7-daemon.service) and dbus-broker now logs "Ignoring duplicate name 'org.freedesktop.secrets'" for the gnome-keyring one. gnome-keyring still gets activated via its legacy org.gnome.keyring name, but no longer owns the Secret Service. It might be worth oo7 (or the Fedora package) shipping its own activation file.