This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12459] New: [RFE] glibc could have a nss_init call that's like res_init but for nsswitch.conf
- From: "rstrode at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 2 Feb 2011 17:03:25 +0000
- Subject: [Bug libc/12459] New: [RFE] glibc could have a nss_init call that's like res_init but for nsswitch.conf
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=12459
Summary: [RFE] glibc could have a nss_init call that's like
res_init but for nsswitch.conf
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper.fsp@gmail.com
ReportedBy: rstrode@redhat.com
Right now, long running processes don't get updates to the nsswitch module list
in /etc/nsswitch.conf if nscd isn't running. This is because libc caches the
module list in memory after it's initially read.
It would be useful if there was a nss_init() call akin to res_init() that would
flush the cached list and reload it.
A relevant downstream bug report is here:
https://bugzilla.redhat.com/show_bug.cgi?id=621700
In that case the long running process was GDM (graphical login screen). A user
used authconfig to change their nsswitch.conf and then used fast user switching
(which jumps to a login screen on a different vt) to try to test the new
configuration. Because the login screen was around before the user ran
authconfig, the list of nsswitch modules was stale. This caused a getpwnam()
call to fail, which ultimately lead to login failure.
I worked around this for the above bug report by spawning a helper program to
do the getpwnam() call for me.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.