Re: All services that require a restart from libc6 upgrade...
On Mon, 16 Oct 2000, Ben Collins wrote:
> On Tue, Oct 17, 2000 at 07:03:48AM +1000, Anthony Towns wrote:
> > On Mon, Oct 16, 2000 at 04:23:43PM -0400, Ben Collins wrote:
> > > Some daemons can be affected by libc upgrades. This usually
> > > happens if the daemon uses functions related to NSS (username,
> > > group, hostname and other name lookups). Because these functions
> > > rely on loading modules (libnss_*.so) that may not match the
> > > current libc mapped in memory with the program, it may need to be
> > > restarted when libc is upgraded. The libc package takes care of when
> > > this needs to occur, but your daemon will need to tell libc that
> > > it needs to be restarted in this case.
> >
> > Erm, why should I have to fix libc bugs in my packages? That seems
> > completely and utterly inappropriate.
> >
> > Surely there's some other way to work around this, ideally fixing
> > the root cause not having a zillion other packages work around obscure
> > incompatible changes in libc?
>
> Obviously you don't understand the reason behind this. When daemons are
> running, they carry with them the libc.so.6 that got loaded with it while
> the NSS modules that it uses remain on disk. Now upgrade libc.so.6, and
> the running daemon still has the old one loaded, but the NSS modules are
> new and linked against the new libc.so.6. BOOM. You can't "fix" this, it
> isn't broken. It is inherent in versioned libraries.
I don't understand this. Isn't the point of versioning so that you can
request the library with the proper ABI? If you leave the old libnss_*
files on disk, why doesn't the running daemon --- with the old libc mapped
--- cause the old NSS modules to be loaded?
-S
Reply to: