This is the mail archive of the
mailing list for the glibc project.
Re: upgrade problem
On Thu, Nov 09, 2000 at 09:09:38PM +0100, Frederic Lepied wrote:
> Ben Collins <firstname.lastname@example.org> writes:
> > On Thu, Nov 09, 2000 at 04:27:34PM +0100, Andreas Jaeger wrote:
> > > >>>>> Frederic Lepied writes:
> > >
> > > > 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.
> > >
> > > You didn't reboot at all? I always reboot afterwards to try to do the
> > > update in single user mode - or with as less applications running as
> > > possible.
> > We need to reboot when upgrading Linux now? :) Honestly though, this is
> > the only problem with in place upgrades. It's something I have to contend
> > with now for Debian (once again), and the solution is mostly a hack (a
> > hardcoded list of programs to restart on upgrade).
> > Any ideas from the libc folk about this? :)
> What I plan to do for Mandrake is keep the libnss from old glibc until
> the reboot. For that I have to change the soname of the libnss of the
> new glibc to avoid name clashes. WDYT ?
I thought about that aswell. Some ideas that came to mind were making the
NSS module name lookups check for the module names in this order:
- Load module for service "foo"
- Try libnss_foo-2.2.so (where 2.2 is the major.minor of the libc being
- Fallback to libnss_foo.so.2 (the current check)
This way I could keep the old modules around under their non-standard
name. This could even be reversed if it checks for failure on the standard
name, then falls back to the versioned name.
We already have libnss_foo-x.x.x.so nameing scheme (too tight of a name,
IMO), so what's one more symlink? :)
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` email@example.com -- firstname.lastname@example.org -- email@example.com '