https://bugs.kde.org/show_bug.cgi?id=188476
Benjamin Jackson <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Platform|unspecified |Fedora RPMs --- Comment #19 from Benjamin Jackson <[email protected]> --- Concrete root cause for the 5 second delay, with measurements I spent some time instrumenting this on Plasma 6.8.2 because the reports in this bug are mostly "it feels slow" and there was no data on where the time goes. Short version: on a default configuration ksmserver waits for the "Session is exiting" notification to close, that notification is never even sent, and every logout therefore burns the full QTimer::singleShot(5000) fallback. Removing only that wait takes the logout from ~5 s to 0.05 s. Environment: plasmashell/plasma-workspace 6.8.2 (Fedora 44), Qt 6.11.2, Wayland session, ksmserverrc has confirmLogout=false and loginMode=emptySession, no custom notification configuration at all (~/.config/plasmanotifyrc has no [General] section and no exitkde entry, ~/.config/knotificationsrc does not exist). Measured delay, every logout in one session on the same machine (36 logouts, min 4.77 s, max 5.29 s, no outlier below 4.7 s): journalctl -b -o short-precise | grep -E 'org.kde.Shutdown@|Closing windows' (systemd: Started dbus-:[email protected] -> kwin_wayland: Closing windows) 5.23s 4.84s 5.28s 4.79s 4.77s 5.27s 5.27s 4.78s 4.96s 4.79s 5.26s 4.77s 5.18s 4.81s 4.84s 5.27s 4.79s 5.22s 4.78s 5.29s 5.04s 5.15s 4.79s 4.79s 5.22s 5.29s 4.78s 4.82s 4.89s 5.08s 5.21s 5.06s 4.96s 5.05s 4.92s 5.08s 0.05s <- after the change described at the end of this comment strace of the ksmserver process during one logout (filtered to the interesting calls): 22:24:24.134 sendmsg -> org.kde.KWin /Session org.kde.KWin.Session.setState 22:24:24.135 sendmsg -> org.kde.KWin /Session org.kde.KWin.Session.setState ... 5.018 s with no outgoing D-Bus message at all ... 22:24:29.153 ppoll(...) = 0 (Timeout) <- QTimer::singleShot(5000) fired 22:24:29.154 sendmsg -> signal org.kde.Shutdown.logoutFinished(true) (bool true) 22:24:29.155 kwin_wayland: "Closing windows" So the state machine is not waiting for any client, it is sitting on a timer. The notification is never presented. busctl --user monitor --match "interface=org.freedesktop.Notifications" during logouts: default configuration : 0 Notify calls per logout after adding [Event/exitkde] Action=Popup|Sound + a valid Sound= file to ~/.config/plasma_workspace.notifyrc : a Notify call appears with app_name="System Notifications", expire_timeout=-1, and the popup is closed again after exactly 5.0 s (independent probe with notify-send: sent 23:23:00.036, NotificationClosed reason=expired at 23:23:05.058). So both paths end at ~5 s: either the notification is not delivered at all (fallback timer) or the popup lives exactly as long as the fallback timer. Excluded causes, all measured on the same machine: - X11/XWayland clients answering XSMP slowly: killed every X11 client (Snipaste, xwaylandvideobridge) -> still 5.3 s - ksmserverrc clientShutdownTimeoutSecs=1 and legacySaveTimeoutSecs=1 -> 5.22 s - application count: an empty session behaves identically - ksmserver logging: with QT_LOGGING_RULES=*.debug=true and StandardOutput=journal the process prints nothing during the logout phase Root cause, ksmserver/logout.cpp (v6.8.2), KSMServer::completeShutdownOrCheckpoint(): if (state == Shutdown) { KNotification *n = KNotification::event(QStringLiteral("exitkde"), i18nc("@info:status", "Session is exiting"), QPixmap(), KNotification::DefaultEvent); m_waitingForLogoutSound = true; m_killingDone = false; connect(n, &KNotification::closed, this, &KSMServer::logoutSoundFinished); QTimer::singleShot(5000, this, &KSMServer::logoutSoundFinished); startKilling(); } and KSMServer::killingCompleted(): if (m_waitingForLogoutSound) { m_killingDone = true; return; // clients are already gone, we still wait } Q_EMIT logoutFinished(true); /usr/share/knotifications6/plasma_workspace.notifyrc defines [Event/exitkde] with Name/Comment entries (plus translations) only - no Action, no Sound. KNotification therefore presents nothing and never emits closed(), so m_waitingForLogoutSound stays true until the 5 s fallback fires. The wait is unconditional in practice. Verified fix. Removing only the notification wait (nothing else changed): if (state == Shutdown) { startKilling(); } m_waitingForLogoutSound then keeps its initial false, so killingCompleted() emits logoutFinished(true) immediately. Result on the same machine: 0.05 s (01:45:29.269 -> 01:45:29.316). Logout, logout-cancel, session saving and login continue to work; the kill order and the KWin session state calls are unchanged. Suggested directions (any of them removes the delay without losing the intent): 1. Do not gate the session teardown on the notification at all; show it, if it is configured, but call startKilling() right away. 2. Keep the gate but skip it when nothing was presented for that event, e.g. by letting KNotification report whether a presentation happened or by checking KNotifyConfig for the exitkde event before connecting. 3. Keep the wait but make the bound configurable and much smaller, so a silent or unconfigured event cannot add seconds to every logout. -- You are receiving this mail because: You are watching all bug changes.
