On a fresh install of Kubuntu 15.10 Beta 1 RC 1, I get a strange dialogue box. Reproducible: Always Steps to Reproduce: 1. Install Kubuntu 15.10 Beta 1 RC 1 2. Install other desired software (sudo apt update && sudo apt install rekonq oxygen-cursor-theme -y) 3. Reboot 4. Sign into desktop Actual Results: Receive Dialogue box: Configuration file "//.config/kwalletd5rc" not writable. Please contact your system administrator. Expected Results: No dialogue box. I do not even have the file that is not writeable. I only have: mparillo@mparillo-virtual-machine:~$ ls .config/kwal* .config/kwalletrc Is this the normal permissions for .config? drwx------ 10 mparillo mparillo 4096 Aug 26 09:54 .config
Same problem here after upgrading from Kubuntu 15.04 to Kubuntu 15.10 (prerelease) on 2015-09-09. Version of libkf5wallet-bin package is 5.13.0-0ubuntu2.
I have the same problem. It appears when I substitute the graphics driver Noveau with the driver of NVIDIA (355.06). If I install the Noveau driver back, the error message appears no more.
I have thew same issue. Switching from my laptop's nvidia gpu to the intel one removes this error message. I also do not have the local config file kwalletd5rc
Well, this is a WTF kind of bug, in my opinion! Hey Harald, any idea of how switching the graphics driver can affect the wallet. (/me scratching my head)
But, why should I get this message? Since I am running in a VM, I should not be running the NVIDIA driver, should I? Is there a way I can check?
If I create the folder "/.config" (under root dir) with permissions 777, the error message disappears. Nothing is written in that directory, though. So, it seems that writeability of the .config directory is wrongly checked under filesystem root rather than under users home directory.
Correlation doesn't imply causation. I'd suspect that the two presented origins of the issue (installing new packages and removing packages) probably also forced an upgrade of one or more frameworks packages and that in turn somehow broke the config path resolution. Alas, I can't seem to reproduce this on a new install of the daily kubuntu image. So. What we need here is substantially more information. Namely: - /var/log/apt output of actions that caused the bug. - syslog output if anything pertaining to kwallet shows up - journald output if anything pertaining to kwallet shows up (probably would be on the sddm service) - ~/.xsession-errors right after the problem happened Best guess right now is that the kwalletd was stared without the HOME env set, so that's why it would have the silly path.
For me, this no longer appears on fresh installs of Kubuntu Beta-2 RC images.
(In reply to Marco Parillo from comment #8) > For me, this no longer appears on fresh installs of Kubuntu Beta-2 RC images. That was premature. It has come back.
I have upgradeded from Kubuntu 15.04 to 15.10 yesteday and got the same error. For me this looks like a shell script error. E.g.: HOME=$(some | invalid | command | sequence) KWALLET_CONF="/$HOME/.config/kwalletd5rc" # results into ""//.config/kwalletd5rc" I also made an investigation about which process spawns the message: elvenfighter ~ $ ps -eo pid,ppid,args | grep -i kwallet 1196 1174 [kwalletd] <defunct> 1197 1174 /usr/bin/kwalletd5 --pam-login 17 21 1788 1197 /usr/bin/kdialog --title kwalletd5 --msgbox Configuration file "//.config/kwalletd5rc" not writable. Please contact your system administrator. 1793 1 /usr/bin/kwalletd --pam-login 17 20 2489 2442 grep --color=auto -i kwallet elvenfighter ~ $ ps -o pid,ppid,args -p 1174 PID PPID COMMAND 1174 1022 /usr/lib/x86_64-linux-gnu/sddm/sddm-helper --socket /tmp/sddm-auth950d1696-1757-4438-91c7-c06607824e4e --id 1 --start /usr/
Created attachment 94821 [details] Screenshot
This may be related to the KDE wallet migration wizard? From journalctl: org.kde.kwalletd5[1416]: Setting useNewHash to true org.kde.kwalletd5[1416]: Wallet new enough, using new hash org.kde.kwalletd5[1416]: fsize: 2918082162 encrypted.size(): 86560 blksz: 8 org.kde.kwalletd5[1416]: Application ' "KDE Wallet Migration Agent" ' using kwallet without parent window! org.kde.kwalletd5[1416]: Setting useNewHash to true org.kde.kwalletd5[1416]: Wallet new enough, using new hash org.kde.kwalletd5[1416]: Migration failed. org.kde.kwalletd5[1416]: Migration wizard returned an error or has been canceled. The migration agent will resume upon next daemon start org.kde.kwalletd5[1416]: Migration agent stop. sddm[1099]: Checking for pam module sddm[1099]: Got pam-login sddm[1099]: kwalletd: Waiting for hash on 17- sddm[1099]: kwalletd: waitingForEnvironment on: 21 sddm[1099]: kwalletd: Couldn't accept incoming connection sddm[1099]: Hash or environment not received
What I think is going on: * PAM starts kwalletd5 * kwalletd5 starts migration wizard * migration wizard has no $HOME set yet * error It would appear this happens only when there is an existing kwallet4 which it tries to migrate. The main problem is that kwalletd5 gets the environment (including $HOME) from ksmserver, which is started *after* PAM and the migration wizard is started from PAM. Then it all explodes.
Actually, now that I have looked at the code, there is something else going wrong. >sddm[1099]: kwalletd: waitingForEnvironment on: 21 >sddm[1099]: kwalletd: Couldn't accept incoming connection >sddm[1099]: Hash or environment not received The scenario described in my previous comment should not happen because kwalletd is blocked waiting for ksmserver to send the environment vars (including $HOME). But according to your output, kwalletd failed to accept the incoming client connecting to that socket and therefore couldn't read and set the environment. That is the actual problem. Why that happens, I wouldn't know though. Is there something in syslog maybe? About socket operation not being permitted?
There is nothing regarding sockets in my syslog. I found only these: $ sudo cat /var/log/syslog.1 | grep sddm Oct 5 17:46:09 localhost systemd[1]: Started Session 1 of user sddm. Oct 5 17:46:23 localhost sddm[1028]: Oops, secure memory pool already initialized Oct 5 17:46:30 localhost sddm[1028]: Checking for pam module Oct 5 17:46:30 localhost sddm[1028]: Got pam-login Oct 5 17:46:30 localhost sddm[1028]: kwalletd: Waiting for hash on 17- Oct 5 17:46:30 localhost sddm[1028]: kwalletd: waitingForEnvironment on: 20 Oct 5 17:46:30 localhost sddm[1028]: kwalletd: client connected Oct 5 17:46:30 localhost sddm[1028]: kwalletd: client disconnected Oct 5 17:46:35 localhost sddm[1028]: Checking for pam module Oct 5 17:46:35 localhost sddm[1028]: Got pam-login Oct 5 17:46:35 localhost sddm[1028]: kwalletd: Waiting for hash on 17- Oct 5 17:46:35 localhost sddm[1028]: kwalletd: waitingForEnvironment on: 21 Oct 5 17:46:35 localhost sddm[1028]: kwalletd: Couldn't accept incoming connection Oct 5 17:46:35 localhost sddm[1028]: Hash or environment not received ... Oct 6 22:35:23 localhost sddm[1037]: Oops, secure memory pool already initialized Oct 6 22:35:31 localhost sddm[1037]: Checking for pam module Oct 6 22:35:31 localhost sddm[1037]: Got pam-login Oct 6 22:35:31 localhost sddm[1037]: kwalletd: Waiting for hash on 17- Oct 6 22:35:31 localhost sddm[1037]: kwalletd: waitingForEnvironment on: 20 Oct 6 22:35:31 localhost sddm[1037]: kwalletd: client connected Oct 6 22:35:31 localhost sddm[1037]: kwalletd: client disconnected Or what should I look for?
Try "grep -i denied"
This only happens for me when logging in using the proprietary nvidia driver, but If I use autologin with SDDM, I do not see the error message.
Also note my system is an optimus laptop, and the message does not occur using the Intel gpu.
If you're using autologin, it will not start kwallet at all, therefore you will not get any error. Graphics drivers are completely unrelated and (should) have no influence whatsoever.
(In reply to Martin Klapetek from comment #19) > Graphics drivers are completely unrelated and (should) have no influence > whatsoever. Agreed, but I can reproduce it consistently.
For what it's worth I'm also using the nvidia driver and have the error on every single login. I did however just resolve the error by purging the pam-kwallet5 package on kubuntu 15.10. I don't know enough to explore what in this package is causing the issue but the issue did return upon reinstalling the package.
@Harald - can you check if the nvidia package does anything to the pam? Can you guys check your installed libpam-* packages? Do you have any i386 on x86_64 machine? Additionally, can someone please try editing /etc/pam.d/sddm* and comment out (prepend with #) the lines with "auth optional pam_kwallet.so" and a bit lower "session optional pam_kwallet.so" and leave only the pam_kwallet5.so and see what that does?
Commenting out the two pam_kwallet.so did not changed anything to the issue. No i386 libpam package is present on my system. I should also mention that I also have an nvidia card with latest driver (355), although I don't know if it's related.
(In reply to Martin Klapetek from comment #22) > @Harald - can you check if the nvidia package does anything to the pam? > > Can you guys check your installed libpam-* packages? Do you have any i386 on > x86_64 machine? I am on 32-bit. > Additionally, can someone please try editing /etc/pam.d/sddm* and comment > out (prepend with #) the lines with "auth optional pam_kwallet.so" and a bit > lower "session optional pam_kwallet.so" and leave only the pam_kwallet5.so > and see what that does? It made no visible difference. I still see the dialog (perhaps twice; maybe it is the same one re-appearing). Note that I also saw a gnome keyring in addition to both kwallet and kwallet5, though I do not remember installing any gnome apps.
I tried commenting out pam_kwallet.so and the gnome_keyring lines last night and it had no effect on the error message. commenting out pam_kwallet5.so of course eliminated the error though. I see no signs of an i386 package. I tried switching to the open source driver instead of the proprietary nvidia driver and strangely enough like Clay said the error does not appear.
Ok, thanks guys, that eliminates the possibility of kwallet4 and kwallet5 conflicting. The nvidia correlation is strange and I'm sorry for dismissing it so quickly, but it appears to have an effect. @Matt - by switching you mean uninstalling the binary nvidia driver? Or simply changing it in xorg.conf?
I used the driver manager gui on kubuntu for it. I believe it completely uninstalls and reinstalls drivers when switching but I'm not entirely sure.
Hahaha, I'm also using the Nvidia driver. How absurd!
Oddly enough this indeed is 100% reproducible with nvidia drivers installed. I doubt this has to do with the driver itself but rather with the nvidia GL libs doing fun stuff to memory and/or changing startup speed sufficiently to cause/avoid a timing problem. This is a grotesquely disheartening bug that I just spent half a day on and I am still not sure it is fixed because of how fiddly this is to test. Also... bloody modset, what is this? the 80's? Random findings: a) compile flags matter. while the kubuntu build runs into the config problem, a master build with -DCMAKE_BUILD_TYPE=Debug does not (kubuntu uses -DCMAKE_BUILD_TYPE=None -DCMAKE_BUILD_TYPE=Debian, whatever that means). b) the toWalletPipe[0] has the same fd number in both modules for some reason, envSocket OTOH does not. this might be nothing. just an observation c) the failure point is in kwalletd's main.cpp waitForEnvironment; specifically accept() errors out with EINVAL which can be "Socket is not listening for connections, or addrlen is invalid (e.g., is negative).". and indeed addrlen isn't initialized properly... d) in the pam's start_kwallet failing to create the pipes doesn't cause a return of the function, it supposedly should though. not related to the problem at hand All that said this seems to fix it, but I have to do some additional testing diff --git a/src/runtime/kwalletd/main.cpp b/src/runtime/kwalletd/main.cpp index 39b5ae9..e790afe 100644 --- a/src/runtime/kwalletd/main.cpp +++ b/src/runtime/kwalletd/main.cpp @@ -82,8 +82,8 @@ static int waitForEnvironment() printf("kwalletd5: waitingForEnvironment on: %d\n", socketfd); int s2; - socklen_t t; struct sockaddr_un remote; + socklen_t t = sizeof(remote); if ((s2 = accept(socketfd, (struct sockaddr *)&remote, &t)) == -1) { fprintf(stdout, "kwalletd5: Couldn't accept incoming connection\n"); return -1;
https://git.reviewboard.kde.org/r/125717
Git commit f1e6b9d168281196010c44af2eae4587c1d2d088 by Harald Sitter. Committed on 21/10/2015 at 05:38. Pushed by sitter into branch 'master'. initialize socket size with correct value to quote man 2 accept: > The addrlen argument is a value-result argument: the caller must > initialize it to contain the size (in bytes) of the structure pointed > to by addr; on return it will contain the actual size of the peer > address. If addrlen is not correct we may get EINVAL on trying to connect to the environment socket which in turn results in a broken environment of the daemon when started through pam as it will inherit the DM environment. This doesn't have to happen, it does however reproducibly with nvidia-352 on Kubuntu 15.10. Why or how nvidia plays into this is not entirely clear, best bet is that it simply is a coincidence where nvidia would have something allocated in the memory beforehand and since the addrlen stack variable was not explicitly initialized to anything it would could potentially be negative (EINVAL condition) or wrong such that it meets an internal error check within accept(). CHANGELOG: Fixed KWallet configuration file warnings on login FIXED-IN: 5.16 REVIEW: 125717 M +1 -1 src/runtime/kwalletd/main.cpp http://commits.kde.org/kwallet-framework/f1e6b9d168281196010c44af2eae4587c1d2d088
My wallet's working just fine now. Brilliant debugging, thank you!
Several startups with no error message so far. Nice work.
We've been hitting this in Fedora 23 validation testing too: https://bugzilla.redhat.com/show_bug.cgi?id=1266756 for us it seems to be an arch thing; it's reliably reproducible with the 32-bit image, not with the 64-bit image. I'm testing the fix now.
This fix resolved my issue just in time with the final 15.10 Kubuntu release candidate. Perhaps coincidentally, it also resolved this wontfix: https://bugs.kde.org/show_bug.cgi?id=344600&list_id=1305547