Fedora Account System
Red Hat Associate
Red Hat Customer
Hello, I observe strange issue with screenlocker. I use Fedora 44 as a client machine and log in using kerberos. I use gdm as a login manager into a plasma shell wayland session. When logging in and in any other kerberos usage everything works ok except for kscreenlocker_greet. When I lock the screen and unlock after a shot time, everything works OK. But when I lock for longer time (for example for 8 hours) the first unlock fails with kscreenlocker_greet[137368]: pam_sss(kde:auth): received for user username: 4 (Chyba systému). The second attempt to unlock succeeds. I have ticket lifetime long enough so this is not a ticket expiration issue. It i worth to say that when I switch to another logged in user using Alt+F4 and unlock the issue occurs. Also when I press Alt+F3 to get back to the previous user and try to unlock the issue occurs without waiting longer time. Thanks Marek Reproducible: Sometimes
Hi, thank you for your report. Would it be possible to attach the log files from /var/log/sssd covering the failed and then successful login attempt? Please check before if they might contains any sensitive information like e.g. user or host names you do not want to disclose. Additionally the messages from the journal or /var/log/{messages,secure} from the time of the login attempts might help. bye, Sumit
Created attachment 2144020 [details] sssd_LDAP.log
Hello, I submitted anonymized sssd_LDAP.log from the client. In the journal there is only this: kscreenlocker_greet[381296]: pam_sss(kde:auth): authentication failure; logname=username uid=1000123 euid=1000123 tty= ruser= rhost= user=username kscreenlocker_greet[381296]: pam_sss(kde:auth): received for user username: 4 (Chyba systému)
(In reply to Marek Greško from comment #3) > > In the journal there is only this: > > kscreenlocker_greet[381296]: pam_sss(kde:auth): authentication failure; > logname=username uid=1000123 euid=1000123 tty= ruser= rhost= user=username > kscreenlocker_greet[381296]: pam_sss(kde:auth): received for user username: > 4 (Chyba systému) Does this ^^ match timestamp of ``` (2026-06-03 19:21:19): [be[LDAP]] [handle_child_send] (0x0040): [RID#2218] Unable to locate pipe for child pid=381347 ``` ?
(In reply to Alexey Tikhonov from comment #4) > > ``` > (2026-06-03 19:21:19): [be[LDAP]] [handle_child_send] (0x0040): [RID#2218] > Unable to locate pipe for child pid=381347 > ``` Sumit, should this https://github.com/SSSD/sssd/blob/c20c27003a45e82d3ea34a8fa151a270483657bd/src/providers/krb5/krb5_child_handler.c#L541 fallback to starting a new 'krb5_child' instead of failing with 'ENOENT'?
Yes, the timestamp 2026-06-03 19:21:19 matches for both. Marek
(In reply to Alexey Tikhonov from comment #5) > (In reply to Alexey Tikhonov from comment #4) > > > > ``` > > (2026-06-03 19:21:19): [be[LDAP]] [handle_child_send] (0x0040): [RID#2218] > > Unable to locate pipe for child pid=381347 > > ``` > > Sumit, should this > https://github.com/SSSD/sssd/blob/c20c27003a45e82d3ea34a8fa151a270483657bd/ > src/providers/krb5/krb5_child_handler.c#L541 > fallback to starting a new 'krb5_child' instead of failing with 'ENOENT'? Hi, yes. We might want to consider if it should be only done for methods which do not depend on a state (password, 2FA, Smartcard/PKINIT) and still error out on the others (passkey, IdP) but I think for a start it would be better to do best effort and start a new krb5_child to see if authentication can proceed. @marek.gresko can you send all lines from krb5_child.log for PID 381347 as well? Most probably they are much earlier than the login attempt. bye, Sumit
Hello, as I have written, there are no such logs. The krb5_child stopped logging before the event. Probably it has some detection of similar logs and does not log it. I can try to reboot and then reproduce the issue. Or I can try to identify an older event which is in the logs. Marek
Created attachment 2144250 [details] krb5_child.log from different event Hello, this is krb5_child.log from 2 different events on 1. 6. 2026. The first event triggered the issue at 20:12:41 with good password followed by second event with bad password at 20:12:48. I am not sure why the log is not ordered and the two issues mix in it. Marek
(In reply to Marek Greško from comment #8) > Hello, > > as I have written, there are no such logs. You need to add 'debug_level = 9' in the domain section of 'sssd.conf and restart SSSD service. https://sssd.io/troubleshooting/basics.html#sssd-debug-logs
Hi, my current assumption is that 'kscreenlocker_greet' calls `pam_start()` and `pam_authenticate()` at the time it is started. This triggers an operation in SSSD to initiate a Kerberos authentication to determine which authentication methods are available for the user trying to log in. This is done by `krb5_child` and in the latest versions of SSSD it keeps running and waits to finish the authentication with the credentials provided by the user. If the screen is locked for a long time, `krb5_child` is most probably stopped and the SSSD backend does not properly detect this. As a result it still thinks `krb5_child` is waiting for a reply and tries to send the credentials when the user is trying to authenticate hours later. If you see a message like (2026-06-03 19:21:19): [be[LDAP]] [handle_child_send] (0x0040): [RID#2218] Unable to locate pipe for child pid=381347 in the backend logs I would expect that `krb5_child` with the corresponding PID is started hours before in `krb5_child.log` and with `debug_level = 9` it might be even logged why this `krb5_child` instances terminated. HTH bye, Sumit
Created attachment 2144534 [details] journal with debug_level=9
Created attachment 2144535 [details] krb5_child.log with debug_level=9
Hello, we uploaded the krb5_child.log and joutnalctl output after setting debug_level=9. The event occured at 21:04 and is followed by successful unlock. It seems the issue occured quite soon after reboot and login (login at 20:30). Today I verified that the issue did not occur after console switching, so the original issue description might be misleading. Thanks Marek
Hello, were the log files of any use? O is any other debugging needed? Thanks Marek
(In reply to Marek Greško from comment #15) > Hello, > > were the log files of any use? O is any other debugging needed? > > Thanks > > Marek Hi, sorry, I forgot to reply. Yes, they confirm my assumption. The krb5_child.log shows that it was started at 20:47:33 to collect to available authentication methods but never got an authentication attempt back. The PID (7945) was not cleared in the backend so that the next attempt failed because there was no process anymore which could handle it. bye, Sumit
Hello, is there any way to workaround the problem? Either set some long timeout for the process to exist or something like that? The issue is very annoying. Thanks Marek
(In reply to Marek Greško from comment #17) > Hello, > > is there any way to workaround the problem? Either set some long timeout for > the process to exist or something like that? The issue is very annoying. Hi, unfortunately I cannot think of a workaround from the SSSD side because the related timeout is hardcoded to 5 minutes. Maybe there is a way to tell the KDE lock screen to not call `pam_authenticate()` immediately after locking the screen but only after some user interaction? bye, Sumit > > Thanks > > Marek