On Tue, 13 Nov 2001, Ivan Popov wrote:

> I cannot tell absolutely for sure that it is symlinks that trigger the
> problem, but it feels really the most probable. And at any rate it is
> concurrent access to executable images that suffers.

A more analysis reveals that the effect may be triggered by concurrent
access to a directory (with no symlinks in its path), the suffering party
are libraries that are symlinks in that directory.

/coda/some/where/libA.so.1 -> /coda/somewhere/else/libA.so.1
                 libB.so.5 -> /coda/another/place/libB.so.5
                 libC.so.2 -> /coda/something/libC.so.5

progA needs libA and libC, progB needs libB and libC

(libC is already in use by other running processes, i.e. in memory,
because of this or not, but anyway never any problem with libC)

--------------------------------------------
LD_LIBRARY_PATH=/coda/some/where
export LD_LIBRARY_PATH

progA & progB
--------------------------------------------

either progA or progB fails to open corresponding lib - either A or B
"cannot open shared object lib#.so.#: No such file or directory"

But only when trying to start simultaneously.

that is they do not fail while accessing the same resource, but access to
one resource makes access to the other resourse impossible, for the
moment. The common is the directory.

Regards,
--
Ivan