Bug 458825 - /lib/libnsl.so.1: symbol __libc_clntudp_bufcreate, version GLIBC_PRI
Summary: /lib/libnsl.so.1: symbol __libc_clntudp_bufcreate, version GLIBC_PRI
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-08-12 14:52 UTC by Robert Scheck
Modified: 2008-08-13 12:47 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-08-13 12:47:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Robert Scheck 2008-08-12 14:52:01 UTC
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 11:43:58 UTC
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 12:47:30 UTC
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.