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
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Sun Feb 5 16:07:05 2006