Description of problem: I have installed pam-kwallet-5.4.2-1 from updates-testing. This version should be able to open both kwallet4 and kwallet5 at login. However 9 times out of 10 I am still asked for a password for kwallet4 on login. Kwallet5 is always opened without asking for a password. Version-Release number of selected component (if applicable): pam-kwallet-5.4.2-1.fc22.x86_64 How reproducible: Almost always Steps to Reproduce: 1. Install pam-kwallet-5.4.2-1, kde-runtime-15.08.1-2.fc22.x86_64 (for kde4's kwallet), kf5-kwallet-5.14.0-1.fc22.x86_64 (for kf5's kwallet). Optionally also install kde4's and kf5's version of kwalletmanager for easy testing. 2. Make sure you use the same password for login, and the default wallets in both versions 3. Log in to the system and verify which wallets are opened automatically Actual results: On my system, kf5's default wallet is always opened, while kde4's default wallet isn't. I remember it worked a couple of times early on. Expected results: Both default wallets should be opened at login. Additional info: I have been installing several iterations of advisory FEDORA-2015-6b26456127 and other test packages found on bodhi. Perhaps later changes (like perhaps the work on the environment setup?) have influenced this. A couple of links that may be of interest: * https://quickgit.kde.org/?p=kwallet-pam.git&a=shortlog&h=352904c7500e44fcc6788291244882484c7b5962 is the git commit log for pam-kwallet on branch 5.4. Commits on 2015-07-28 are related to getting this functionality to work with both versions of kwallet at the same time. * http://martys.typepad.com/blog/2015/07/kwallet5-can-be-auto-unlocked-during-login-again.html?cid=6a012876e7556d970c01b7c7c640fc970b was the announcement of this feature. The comments have some discussion on initial issues with it, leading to the commits I refer to in the previous link.
Mind you, this will only work with recent sddm too (or any other login manager that is configured to use the new pam_kwallet5 module), https://bodhi.fedoraproject.org/updates/FEDORA-2015-9f996ea146 To test with older sddm, ensure that /etc/pam.d/sddm contains these 4 lines: -auth optional pam_kwallet5.so -auth optional pam_kwallet.so ... -session optional pam_kwallet5.so -session optional pam_kwallet.so
I have tested this with sddm-0.12.0-3 last week and just now with sddm-0.12.0-5 from updates-testing. It remains the same. I also just tried swapping the lines in /etc/pam.d/sddm like so: -auth optional pam_kwallet.so -auth optional pam_kwallet5.so ... -session optional pam_kwallet.so -session optional pam_kwallet5.so This doesn't make a difference. The pam_kwallet5 part works, the older pam_kwallet fails, regardless of the order of the lines in /etc/pam.d/sddm.
I found this today using 'ps -ef | grep <pid-of-sddm-helper>: root 1742 1442 0 18:47 ? 00:00:00 /usr/libexec/sddm-helper --socket /tmp/sddm-auth76ecfbd9-6f4e-4065-8a48-ec0452eaa482 --id 1 --start /usr/bin/startkde --user janssege janssege 1750 1742 0 18:47 ? 00:00:00 [kwalletd] <defunct> janssege 1751 1742 0 18:47 ? 00:00:00 /usr/bin/kwalletd5 --pam-login 14 19 janssege 1752 1742 0 18:47 ? 00:00:00 /bin/sh /usr/bin/startkde Note particularly the <defunct> kwalletd process. Other than that there is also a running kwalletd process: $ ps -ef | grep kwalletd janssege 1750 1742 0 18:47 ? 00:00:00 [kwalletd] <defunct> janssege 1751 1742 0 18:47 ? 00:00:00 /usr/bin/kwalletd5 --pam-login 14 19 janssege 1997 1 0 18:47 ? 00:00:01 /usr/bin/kwalletd --pam-login 14 18 This second process is started by systemctl. So it looks to me sddm starts kwalletd and kwalletd5, but for some reason kwalletd stops prematurely. Either it crashes, or something else causes it to stop before it can be queried. So when login is complete and akonadi wants to access kwalletd, another instance is started. Perhaps that helps narrow down the cause.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.