This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: upgrade problem


Ben Collins <bcollins@debian.org> writes:

> On Thu, Nov 09, 2000 at 11:09:56AM +0100, Frederic Lepied wrote:
> > I have an upgrade problem from glibc 2.1.3 to glibc 2.1.97. When the
> > glibc is updated on the system, a lot of applications stop resolving
> > names and looking up user info. For example openssh server doesn't
> > work anymore without a restart.
> > 
> > After instrumenting the glibc 2.1.3, I found that dynamic loading of
> > the libnss was failing.  It seems to come from the new libnss* 2.1.97
> > libs that need symbols from GLIBC 2.2 which are not present because
> > the running programs are still linked with the 2.1.3 glibc.
> 
> This was the same with the 2.0 -> 2.1 upgrade. I've been dealing with this
> problem myself, and although there is nothing to fix it now (can't go back
> and fix glibc 2.1.3), I've thought about some possible solutions, but they
> all seem like hacks.
> 
> Why don't the modules stay loaded after the first call to them? I thought
> the answer to this was because nsswitch.conf might change, and the modules
> were unloaded in case that changed, but the nss functions don't seem to
> reread this file. Why not leave the modules loaded in memory after the
> first dlopen (<- questions is directed at libc-alpha, not you :)?
> 

From what I have seen, the modules stay loaded but the problem appears
for forking daemons like sshd which loads the module only after the
fork... I'm right or I have missed something ?
-- 
Fred - May the source be with you


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]