Bug 458825 - /lib/libnsl.so.1: symbol __libc_clntudp_bufcreate, version GLIBC_PRI
/lib/libnsl.so.1: symbol __libc_clntudp_bufcreate, version GLIBC_PRI
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-12 10:52 EDT by Robert Scheck
Modified: 2008-08-13 08:47 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-13 08:47:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2008-08-12 10:52:01 EDT
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.
Comment 1 Tomas Mraz 2008-08-13 07:43:58 EDT
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.
Comment 2 Jakub Jelinek 2008-08-13 08:47:30 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.