Description of problem: It looks like the last glibc upgrade had a ABI change somewhere or similar?! So I've added Jakub on Cc, maybe he can confirm such a think or maybe he can see an error related to this? Aug 10 23:15:01 tux crond[11116]: PAM unable to dlopen(/lib/security/pam_unix.so): /lib/libnsl.so.1: symbol __libc_clntudp_bufcreate, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference Aug 10 23:15:01 tux crond[11116]: PAM adding faulty module: /lib/security/pam_unix.so Aug 10 23:15:01 tux crond[11116]: PAM unable to dlopen(/lib/security/pam_access.so): /lib/libnsl.so.1: symbol __libc_clntudp_bufcreate, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference Aug 10 23:15:01 tux crond[11116]: PAM adding faulty module: /lib/security/pam_access.so Aug 12 05:00:01 tux crond[31035]: (robert) FAILED to authorize user with PAM (Modul ist nicht bekannt) Aug 12 05:00:01 tux crond[31034]: (vnstat) FAILED to authorize user with PAM (Modul ist nicht bekannt) Aug 12 05:01:01 tux crond[31150]: (root) FAILED to authorize user with PAM (Modul ist nicht bekannt) "Modul ist nicht bekannt" means "Module is unknown". A rebuild of PAM against latest rawhide and restarting the services made this problem going away for me. Note that just restarting the services did not solve my problem, thus the try for a rebuild which solved it. Version-Release number of selected component (if applicable): pam-1.0.1-5 cronie-1.2-1 How reproducible: Everytime for me here. Actual results: Various odd error messages in syslog. Expected results: No odd error messages in syslog etc.
glibc should never be backwards ABI incompatible with previous version. If it was just some mistake in rawhide glibc and pam really has to be rebuilt, please reassign back.
This is not an ABI change in any way. Just a new GLIBC_PRIVATE symbol has been added to libc.so and the new libnsl.so.1 uses it, similar thing would happen with any other added symbol that some other library needs. The problem is that during glibc upgrade some daemons/long running programs might be dynamically linked against the older glibc, but not have all the libraries dlopened, then glibc (or any other library) is upgraded and then the daemon/long running program dlopens libnsl or some othernew library. The old libc.so the program has loaded obviously doesn't have the new symbol, so dlopen fails. The solution is to restart all the services or reboot. glibc upgrade restarts sshd and init, so that you can remotely fix up things on the box and that shutdown is clean, but it is not appropriate to restart everything without user's consent.