[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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?


Reply to: