Description of problem: With Fedora37 and a KDE/Plasma, sddm login under X11 authenticated using NIS the user does not have access to audio devices and probably other things. There is no /run/users/<userid> directory for them and XDG_RUNTIME_DIR is not set. Running "systemctl restart systemd-userdbd" prior to login fixes the issue. so it looks like systemd-userdbd is ignoring NIS users before ypbind is up and running. With gdm you cannot even login. Version-Release number of selected component (if applicable): How reproducible: Solid. Steps to Reproduce: 1. Setup NIS authentication 2. Setup KDE/PLASMA/sddm login 3.Try and login as a user authenticated with NIS Actual results: Expected results: Additional info: There is some info on the bug at: https://bugzilla.redhat.com/show_bug.cgi?id=2082843
Can you log in successfully if you boot into multi-user.target and login on tty?
If I login as a NIS user on a virtual console terminal, then yes I can login, but as per the sddm login session there is no /run/user/<userid> directory created and all of the XDG_* environment variables are not set. If I run "systemctl restart systemd-userdbd" then after this logins on both a console tty and through sddm are fine. As a workaround i have created a simple systemd unit file to restart systemd-userdbd after ypbind has started. I will attach this.
Created attachment 1932122 [details] Workaround systemd-userdbd-restart.service This is copied to /usr/lib/systemd/system/ and then: "systemctl enable systemd-userdbd-restart" is run to enable it at the next boot.
nss_nis already has an override for systemd-userdbd.service: /usr/lib/systemd/system/systemd-userdbd.service.d/nss_nis.conf If something more needs to be added, it should be added there.
I don't think that anything useful can be added to /usr/lib/systemd/system/systemd-userdbd.service.d/nss_nis.conf. We could only add something to make it start after ypbind but I think (others have said) this would yield a dependency loop and I suspect systemd-userdbd needs to be running well before ypbind and networking anyway and not have a network timeout possibility. I believe the real issue is within the systemd-userdbd daemon itself. If NIS is in use it should attempt to connect/reconnect while running. I presume it must do this already for other network authentication systems such as LDAP.
I looked into this some more. The first issue is why 'userdbctl user myusername' says 'User myusername does not exist.' but 'userdbctl --service=x user myusername' returns some data. userdb has a concept of "services", provided by listening sockets in a well-known directory. One of them is /run/systemd/userdb/io.systemd.Multiplexer, which effectively connects to userdbd.service. But userdb also implements a fallback to nss for compatibility with normal lookups, and not as a "service", but as a separate step. When --service is not specified, userdbctl just connects to /run/systemd/userdb/io.systemd.Multiplexer and the query is resolved on the server side. When --service is specified, userdbctl tries to connect to /run/systemd/userdb/x, which fails. It then implements the nss fallback on client side. This is possibly a buglet: I'm not sure if the nss fallback should be used at all when a specific service is requested. But it isn't directly relevant for this bug: it just explains why the workaround works. The real issue is why the lookup via userdbd.service fails. The difference is that with the client side lookup, we start a fresh process every time. With the server side lookup, there's a long-running process. userdbd doesn't do any explicit caching, in case of the nss fallback it always just calls getpwnam_r(). The reasons that this does not work is that apparently nss-nis does not update the state after ypbind has been started. I don't know the nss-nis code very well, but it seems to call yp_get_default_domain() [1]. That does some caching… [2]. My guess is that this goes wrong somewhere and the module does not notice that ypbind has been started or the domain name has changed. [1] https://github.com/thkukuk/libnss_nis/blob/master/src/nis-network.c#L217 [2] https://sources.debian.org/src/libnsl/1.3.0-2/src/yp_get_default_domain.c/?hl=32#L32
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
*** Bug 2160898 has been marked as a duplicate of this bug. ***