On Fri February 3 2006 17:06, Michael S. Zick wrote: > On Fri February 3 2006 10:14, Michael S. Zick wrote: > > Group, > > > > An update on the discussions in m-l threads: > > re: http://list.linux-vserver.org/archive/vserver/msg09336.html > > re: http://list.linux-vserver.org/archive/vserver/msg12349.html > > > - - - snip - - - > This should be the last part of what turned out to be a three part message.
(After a couple of days of RTFM ...) As to the original question: "Can some sort of test be created ..." Consider this situation: User has a host system, running an arbitrary version/patch flavor/option set of glibc ... User has just populated the file system with a guest software system using an arbitrary *libc ... Now, for this situation, construct a test the user can run to see if they might run into trouble with the glibc name service system either failing or worse, returning the data from the host definitions rather than the guest definitions during either new context creation or new context entry. (That turns out to be a challenging test specification.) The problem exists because the nss services in glibc are provided by dynamic linking of external DSOs, even in a staticly linked application. AND: For most hardware, glibc performs "lazy linking" (on call linking). AND: The dynamic linker of glibc can not unlink a DSO from an executing process image and re-link that same process image with a different DSO. (Even if glibc-2.4.x provides that last feature - note the "arbitrary glibc" in the problem specification.) - - - Testing for glibc nss failure of process(es) executing in two contexts: Not an easy task. Also would require artificial set-up in user's host and/or guest software system. Q.E.D: Not practical. - - - Testing for other glibc failures of process(es) executing in two contexts: This one might be practical. The roots of the problem given above also apply to internationalization in glibc (on-call linking of an external DSO even in a staticly linked application). The tests would require the host and guest locale settings to differ and detecting if a "two context" process is grabbing the wrong locale data/coversions. - - - The work arounds - - Staticly link "two context" applications against a *libc that does not provide nss and internationalization as external, link on-call, DSOs - - The glibc case (this fails the "arbitrary glibc" part of the requirements) - Link "two context" applications either dynamicly or staticly against glibc. (Static linking gives a larger image but quicker start-up time) - Disable nscd if running in the host (or never start it; I.E: no config file) (nscd --shutdown) - Enable the "bind-now" feature in the environment of "two context" applications when creating the process image. (This feature is a glibc build time option - your glibc might not include it.) - - - Why call the previous "work arounds" ? - - Both the glibc and non-glibc "work arounds" lock the "two context" process image to use the host software system implementations. It is conceivable that the guest software system is incompatible with the "locked in" implementation. - - The glibc "work around" can also be "locked in" to the guest implementation using a combination of LD_LIBRARY_PATH and BIND_NOW. - - The point is, the process image is only _KNOWN_ to be compatible with either the host or the guest software system. - - - The solution - - Don't do that. - Immediately after making the "context change" system call, create a new process image using the new context software system, communicate commands that might make nss or internationalization calls to the proper, context specific, process image. Note 1: Open file descriptors that are not marked "close on exec" are passed to the process image in the new context. Note 2: The high level, VServer tools are Bash scripts - this means that the executing Bash process image is a "two context" application. Note 3: ldconfig has options that allow the creation of the (to be) proper ld.so.cache for the file system of the new context from outside of that file system. - - - > I.E: A lot of work for no noticeable benefit or even lost functionality. > > When the linux dynamic loader can unlink and relink a different DSO > in a process image - the situation might change. That feature has been > on the glibc wish list for nearly a decade - don't hold your breath. > > None of this means that you can not use glibc with the dynamic nss enabled, > it only places restrictions on version compatibility of the libraries in > the host and the guest. > I hope that having this thread in the m-l archives is a help to someone. Mike _______________________________________________ Vserver mailing list [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
