I think I have the same error. It's happening for quite some time already after I changed my user password and of course I changed also kwallet password to be the same. I'm not sure it was the cause, maybe I updated packages at the same time and this is just a coincidence. After logging into plasma after opening Chromium or when wi-fi is trying to connect, dialog box pops up asking for my password. If enter the same password and kwallet unlocks.

Plasma 5.14.3, but I believe it happened with previous versions as well. lightdm 1.28.0-1. Arch linux.

ноя 23 08:39:34 stone0495 systemd[1]: session-c1.scope: Killing process 780 (lightdm) with signal SIGTERM.
ноя 23 08:39:34 stone0495 systemd[1]: session-c1.scope: Killing process 791 (lightdm-webkit2) with signal SIGTERM.
ноя 23 08:39:34 stone0495 systemd[1]: session-c1.scope: Killing process 811 (WebKitNetworkPr) with signal SIGTERM.
ноя 23 08:39:34 stone0495 systemd[1]: session-c1.scope: Killing process 813 (WebKitWebProces) with signal SIGTERM.
ноя 23 08:39:34 stone0495 systemd[1]: Stopping Session c1 of user lightdm.
ноя 23 08:39:34 stone0495 lightdm[780]: pam_unix(lightdm-greeter:session): session closed for user lightdm
ноя 23 08:39:34 stone0495 lightdm[983]: pam_kwallet5(lightdm:setcred): pam_kwallet5: pam_sm_setcred
ноя 23 08:39:34 stone0495 lightdm[983]: pam_unix(lightdm:session): session opened for user shohov by (uid=0)
ноя 23 08:39:34 stone0495 kernel: audit: type=1006 audit(1542955174.763:126): pid=983 uid=0 old-auid=4294967295 auid=1000 tty=(none) old-ses=4294967295 ses=4 res=1
ноя 23 08:39:34 stone0495 systemd-logind[393]: New session 4 of user shohov.
ноя 23 08:39:34 stone0495 systemd[1]: Started Session 4 of user shohov.
ноя 23 08:39:34 stone0495 lightdm[983]: pam_kwallet5(lightdm:session): pam_kwallet5: pam_sm_open_session
ноя 23 08:39:34 stone0495 lightdm[989]: pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket
ноя 23 08:39:34 stone0495 lightdm[989]: pam_kwallet5-kwalletd: Couldn't listen in socket
ноя 23 08:39:34 stone0495 systemd[1]: Stopped Session c1 of user lightdm.
ноя 23 08:39:34 stone0495 lightdm[983]: pam_kwallet5(lightdm:session): pam_kwallet5: Couldn't fork to execv kwalletd
ноя 23 08:39:34 stone0495 systemd-logind[393]: Removed session c1.
ноя 23 08:39:34 stone0495 systemd[948]: Started D-Bus User Message Bus.

I seem to be able to reproduce this on Arch Linux

The same issue in Gentoo:

lightdm 2.0.6
kwallet-pam - 5.15.1
pam - 1.3.1
plasma-workspace - 5.15.1
plasma-framework - 5.55.0


PAM files:

1. lightdm
-----------
auth	include		system-local-login
-auth		optional	pam_gnome_keyring.so
-auth		optional	pam_kwallet5.so

account	include		system-local-login

password	include		system-local-login
-password	optional	pam_gnome_keyring.so use_authtok

session	include		system-local-login
-session		optional	pam_gnome_keyring.so auto_start
-session	optional	pam_kwallet5.so auto_start


2. system-local-login
---------------------
auth		include		system-login
account		include		system-login
password	include		system-login
session		include		system-login



3. system-login
---------------
auth		required	pam_tally2.so onerr=succeed
auth		required	pam_shells.so 
auth		required	pam_nologin.so 
auth		include		system-auth
account		required	pam_access.so 
account		required	pam_nologin.so 
account		include		system-auth
account		required	pam_tally2.so onerr=succeed 
password	include		system-auth
session         optional        pam_loginuid.so
session		required	pam_env.so 
session		optional	pam_lastlog.so silent 
session		include		system-auth
session		optional	pam_motd.so motd=/etc/motd
session		optional	pam_mail.so


4. system-auth
--------------
auth		required	pam_env.so 
auth		required	pam_unix.so try_first_pass likeauth nullok 
auth		optional	pam_permit.so
 
account		required	pam_unix.so 
account		optional	pam_permit.so
 
password	required	pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 
password	required	pam_unix.so try_first_pass use_authtok nullok sha512 shadow 
password	optional	pam_permit.so
 
session		required	pam_limits.so 
session		required	pam_env.so 
session		required	pam_unix.so 
session		optional	pam_permit.so

session        optional        pam_loginuid.so
-session        optional        pam_systemd.so

The same issue still persists.
Actually I have never been able to use pam-kwallet properly.

The system is still Gentoo, though some of the versions are a lot more recent:

lightdm 1.30.0
kwallet-pam - 5.17.2
pam - 1.3.1
plasma-workspace - 5.17.2
plasma-framework - 5.63.0

PAM files are the same as in my previous post.

The errors are like as in @Dmitry's logs... 

I added some extra debug code in the pam_kwallet.c to get some extra info:

lightdm[940510]: pam_kwallet5(lightdm:auth): (null): pam_sm_authenticate
lightdm[940510]: pam_kwallet5(lightdm:setcred): pam_kwallet5: pam_sm_setcred
lightdm[940510]: pam_kwallet5(lightdm:session): pam_kwallet5: pam_sm_open_session
lightdm[940567]: pam_kwallet5: final socket path: /run/user/501/kwallet5.socket
lightdm[940567]: pam_kwallet5-kwalletd: Couldn't listen in socket because: 95-Operation not supported
lightdm[940510]: pam_kwallet5(lightdm:session): pam_kwallet5: Couldn't fork to execv kwalletd (default state of the switch) because of status: 256-1

I am not an expert in sockets coding and operations, but it seems there is a problem with the socket usage at listen(envSocket, 5) level - with this error 95.
Besides the forked child at start_kwallet(...) obviously exits with error because of this(256 is the status value and the 1 is the WEXITSTATUS(status))
The folder /run/user/501 has the appropriate user permissions

Anyone of the developers?
Do you need more debug info?
This is already a year old problem that has not been still resolved :(

I have the issue too also on Gentoo

ное 20 01:05:28 lightdm[11976]: pam_kwallet5(lightdm:session): pam_kwallet5: pam_sm_close_session
ное 20 01:05:28 lightdm[11976]: pam_kwallet5(lightdm:setcred): pam_kwallet5: pam_sm_setcred
ное 20 01:05:28 org.kde.kwalletd5[794]: kwalletd5: Checking for pam module
ное 20 01:05:28 lightdm[13224]: pam_kwallet5(lightdm-greeter:setcred): (null): pam_sm_setcred
ное 20 01:05:28 lightdm[13224]: pam_kwallet5(lightdm-greeter:session): (null): pam_sm_open_session
ное 20 01:05:28 lightdm[13224]: pam_kwallet5(lightdm-greeter:session): pam_kwallet5: open_session called without kwallet5_key
ное 20 01:05:32 lightdm[13247]: pam_kwallet5(lightdm:auth): (null): pam_sm_authenticate
ное 20 01:05:32 lightdm[13224]: pam_kwallet5(lightdm-greeter:session): pam_kwallet5: pam_sm_close_session
ное 20 01:05:32 lightdm[13224]: pam_kwallet5(lightdm-greeter:setcred): pam_kwallet5: pam_sm_setcred
ное 20 01:05:32 lightdm[13247]: pam_kwallet5(lightdm:setcred): pam_kwallet5: pam_sm_setcred
ное 20 01:05:32 lightdm[13247]: pam_kwallet5(lightdm:session): pam_kwallet5: pam_sm_open_session
ное 20 01:05:32 lightdm[13254]: pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket
ное 20 01:05:32 lightdm[13254]: pam_kwallet5-kwalletd: Couldn't listen in socket
ное 20 01:05:32 lightdm[13247]: pam_kwallet5(lightdm:session): pam_kwallet5: Couldn't fork to execv kwalletd

I finally got it to work. I haven't found out the reason why the call to listen fails with EOPNOTSUPP, but I changed the code of both kwallet-pam and kwalletd to use a named pipe to pass the environment variables. Hence there is no call to listen any more. I don't know if this is a real solution because it's not clear to me why the developers decided to use a socket instead of a pipe, but maybe there is some reason I don't see. Anyway here are the diffs:
kwalletd main.cpp: https://pastebin.com/Y2gvuqQx
pam_kwallet.c: https://pastebin.com/g5knsLHS
pam_kwallet_init: https://pastebin.com/n3KGSb5J

(In reply to stefano.aloe2 from comment #6)
> I finally got it to work. (...) I changed the code of both kwallet-pam and
> kwalletd to use a named pipe to pass the environment variables.
I applied your patches and can confirm that they are also working on my machine (Arch Linux x86_64). Thanks!

Don't use pastebin for patches.

Either attach it, or - much better - create a phabricator diff.

Any reasons nobody has tried to mainline the patches that do -in fact- fix this issue? even if they were presented in the right way, this issue could be fixed by just those simple patches being applied, or similar versions of them.

The patches are wrong, they change the behaviour of two things that are not released in sync (kwalletd and pam-kwallet), so they would break every single user for a while until everyone was using the new version, doesn't seem like a reasonable solution.

Maybe instead of putting pressure here you'll could put pressure in https://github.com/canonical/lightdm/issues/134

(In reply to Albert Astals Cid from comment #10)
> The patches are wrong, they change the behaviour of two things that are not
> released in sync (kwalletd and pam-kwallet), so they would break every
> single user for a while until everyone was using the new version, doesn't
> seem like a reasonable solution.
> 
> Maybe instead of putting pressure here you'll could put pressure in
> https://github.com/canonical/lightdm/issues/134

Ah. Fair.
Well, this same error appears if you use KWallet on literally anything other than SDDM, so it's 100% not only a lightdm error 
Just trying to use startx, and configuring /etc/pam/login to open KWallet, it fails with this exact error. Same on GDM, or anything *but* SDDM. This feels like a KWallet error for sure.

I'll chime in there, though :)

(In reply to David Rubio from comment #11)
> (In reply to Albert Astals Cid from comment #10)
> > The patches are wrong, they change the behaviour of two things that are not
> > released in sync (kwalletd and pam-kwallet), so they would break every
> > single user for a while until everyone was using the new version, doesn't
> > seem like a reasonable solution.
> > 
> > Maybe instead of putting pressure here you'll could put pressure in
> > https://github.com/canonical/lightdm/issues/134
> 
> Ah. Fair.
> Well, this same error appears if you use KWallet on literally anything other
> than SDDM, so it's 100% not only a lightdm error 
> Just trying to use startx, and configuring /etc/pam/login to open KWallet,
> it fails with this exact error. Same on GDM, or anything *but* SDDM. This
> feels like a KWallet error for sure.
> 
> I'll chime in there, though :)

Oh. I read the bug report now. Well, one question would be why it doesn't work with startx either, even if PAM is configured to open the wallet.

(In reply to David Rubio from comment #11)
> (In reply to Albert Astals Cid from comment #10)
> > The patches are wrong, they change the behaviour of two things that are not
> > released in sync (kwalletd and pam-kwallet), so they would break every
> > single user for a while until everyone was using the new version, doesn't
> > seem like a reasonable solution.
> > 
> > Maybe instead of putting pressure here you'll could put pressure in
> > https://github.com/canonical/lightdm/issues/134
> 
> Ah. Fair.
> Well, this same error appears if you use KWallet on literally anything other
> than SDDM, so it's 100% not only a lightdm error 
> Just trying to use startx, and configuring /etc/pam/login to open KWallet,
> it fails with this exact error. Same on GDM, or anything *but* SDDM. This
> feels like a KWallet error for sure.
> 
> I'll chime in there, though :)

It worked fine with gdm last time i tried.

(In reply to David Rubio from comment #12)
> (In reply to David Rubio from comment #11)
> > (In reply to Albert Astals Cid from comment #10)
> > > The patches are wrong, they change the behaviour of two things that are not
> > > released in sync (kwalletd and pam-kwallet), so they would break every
> > > single user for a while until everyone was using the new version, doesn't
> > > seem like a reasonable solution.
> > > 
> > > Maybe instead of putting pressure here you'll could put pressure in
> > > https://github.com/canonical/lightdm/issues/134
> > 
> > Ah. Fair.
> > Well, this same error appears if you use KWallet on literally anything other
> > than SDDM, so it's 100% not only a lightdm error 
> > Just trying to use startx, and configuring /etc/pam/login to open KWallet,
> > it fails with this exact error. Same on GDM, or anything *but* SDDM. This
> > feels like a KWallet error for sure.
> > 
> > I'll chime in there, though :)
> 
> Oh. I read the bug report now. Well, one question would be why it doesn't
> work with startx either, even if PAM is configured to open the wallet.

I've no idea and no interest in debugging that. If you're interested, ask yourself who is loading pam_kwallet5.so before X starts? When sddm it's sddm, when gdm it's gdm, when lightdm is lightdm, if you're not using any of those, who is doing it?

(In reply to Albert Astals Cid from comment #14)
> (In reply to David Rubio from comment #12)
> > (In reply to David Rubio from comment #11)
> > > (In reply to Albert Astals Cid from comment #10)
> > > > The patches are wrong, they change the behaviour of two things that are not
> > > > released in sync (kwalletd and pam-kwallet), so they would break every
> > > > single user for a while until everyone was using the new version, doesn't
> > > > seem like a reasonable solution.
> > > > 
> > > > Maybe instead of putting pressure here you'll could put pressure in
> > > > https://github.com/canonical/lightdm/issues/134
> > > 
> > > Ah. Fair.
> > > Well, this same error appears if you use KWallet on literally anything other
> > > than SDDM, so it's 100% not only a lightdm error 
> > > Just trying to use startx, and configuring /etc/pam/login to open KWallet,
> > > it fails with this exact error. Same on GDM, or anything *but* SDDM. This
> > > feels like a KWallet error for sure.
> > > 
> > > I'll chime in there, though :)
> > 
> > Oh. I read the bug report now. Well, one question would be why it doesn't
> > work with startx either, even if PAM is configured to open the wallet.
> 
> I've no idea and no interest in debugging that. If you're interested, ask
> yourself who is loading pam_kwallet5.so before X starts? When sddm it's
> sddm, when gdm it's gdm, when lightdm is lightdm, if you're not using any of
> those, who is doing it?

Usually to use PAM with startx (as far as I'm aware) you have to load it before X starts, which might be an issue here if kwallet5 requires X (anything special that makes it require such?)

Created attachment 134311 [details]
patch to solve the listen problem

The previous patch I had posted was actually a quick fix, since, as I wrote, I didn't really find out the cause of the problem with listen. However, upon further inspection, it turned out that the problem was caused by closing all the file descriptors greater than 2 before calling socket. By adding some debug code I found out that the socket was given file descriptor 3, and calling getsockopt with SO_TYPE on this fd always returned 2, which is SOCK_DGRAM, regardless of which type of socket was required in the call to socket. I don't know the reason for this behavior, the only thing I noticed is that when execute_kwallet is called the file descriptor 3 is indeed assigned to another socket, but I've no clue on the origin of this socket. Since we don't want kwallet to inherit irrelevant file descriptors from his parent, I replaced the call to close with a call to fcntl, which sets the FD_CLOEXEC flag. This solves the problem and should prevent undesired fd inheritance as well.

I would really appreaciate if you could send a merge request via https://invent.kde.org/plasma/kwallet-pam

https://community.kde.org/Infrastructure/GitLab#Submitting_a_merge_request

fwiw we have a positive downstream test report: https://bugs.gentoo.org/717606#c5

stefano.aloe2@gmail.com I see you don't want to go to the proper channel to get your patch reviewed and merged.

Can we at least get a name to attach to the code? (When we review it and find it to be correct?)

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwallet-pam/-/merge_requests/2

Sorry for the huge delay. I was extremely busy in the last month and in the end I just forgot to send a merge request. I'm not really familiar with git, but I should have allowed collaboration on my request, or at least I hope so, since I'm still very busy and probably I won't be able to work again on this before March.

Git commit 8f899902e6a3be8ad4948eb1ebdf679186aa20a7 by Stefano Aloé.
Committed on 17/01/2021 at 22:16.
Pushed by aacid into branch 'master'.

Avoid socket listening error

Closing all file descriptor above 3 is causing problem to socket() and listen(). Setting FD_CLOEXEC on them solves the problem and should have exactly the same behavior.

M  +4    -2    pam_kwallet.c

https://invent.kde.org/plasma/kwallet-pam/commit/8f899902e6a3be8ad4948eb1ebdf679186aa20a7

Git commit 06cd94634feb70dfa7e2f8695b97317cb2ebe44c by Albert Astals Cid, on behalf of Stefano Aloé.
Committed on 19/01/2021 at 22:05.
Pushed by aacid into branch 'Plasma/5.20'.

Avoid socket listening error

Closing all file descriptor above 3 is causing problem to socket() and listen(). Setting FD_CLOEXEC on them solves the problem and should have exactly the same behavior.
(cherry picked from commit 8f899902e6a3be8ad4948eb1ebdf679186aa20a7)

M  +4    -2    pam_kwallet.c

https://invent.kde.org/plasma/kwallet-pam/commit/06cd94634feb70dfa7e2f8695b97317cb2ebe44c

Git commit 82a93cca1da4d2a4eeb450804c4895f43053d1f1 by Albert Astals Cid, on behalf of Stefano Aloé.
Committed on 19/01/2021 at 22:06.
Pushed by aacid into branch 'Plasma/5.18'.

Avoid socket listening error

Closing all file descriptor above 3 is causing problem to socket() and listen(). Setting FD_CLOEXEC on them solves the problem and should have exactly the same behavior.
(cherry picked from commit 8f899902e6a3be8ad4948eb1ebdf679186aa20a7)

M  +4    -2    pam_kwallet.c

https://invent.kde.org/plasma/kwallet-pam/commit/82a93cca1da4d2a4eeb450804c4895f43053d1f1