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: 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: PAM adding faulty module: /lib/security/pam_unix.so
Aug 10 23:15:01 tux crond: 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: PAM adding faulty module: /lib/security/pam_access.so
Aug 12 05:00:01 tux crond: (robert) FAILED to authorize user with PAM (Modul ist nicht bekannt)
Aug 12 05:00:01 tux crond: (vnstat) FAILED to authorize user with PAM (Modul ist nicht bekannt)
Aug 12 05:01:01 tux crond: (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):
Everytime for me here.
Various odd error messages in syslog.
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.