https://bugs.kde.org/show_bug.cgi?id=509680
--- Comment #28 from CarlosE <[email protected]> --- V4 of the MR does not work on my machine. As V1 of the MR stated[1], PAM_KWALLET5_LOGIN is also exported to the entire user session/D-Bus activation environment during login (intentionally, if my understanding of kwallet-pam's README is correct), so it's not a reliable indicator of a D-Bus launch (that is, unless the D-Bus service file is wrapped with `env -u` or some other equivalent solution). V3 (using hash == nullptr) is the one that worked best on my machine. If my interpretation is correct, PAM_KWALLET5_LOGIN can be expected to be present in a D-Bus activated ksecretd only if it can conflict with kwallet-pam; in that case, `hash == nullptr && getenv("PAM_KWALLET5_LOGIN)` can be used as a trigger for the "waiting mode", with a more generous timeout since the risk of false positives is smaller. A dead-end I investigated, for posterity: starting `/usr/bin/plasma_waitforname org.freedesktop.impl.portal.desktop.kwallet` (seems to be used for a similar purpose in Plasma, namely preventing notifications from being processed before the notification daemon is started), even if started very early in the login process, does not work. [1] https://invent.kde.org/frameworks/kwallet/-/blob/7fc9117a9f2bf28d92e7d0b3a390841255209919/src/runtime/ksecretd/main.cpp#L232 -- You are receiving this mail because: You are watching all bug changes.
