You are running a container with its own image right? So is /usr/lib/x86_64
in the container's file system or the host file system?
On Mon, Oct 17, 2016 at 6:47 AM, Mark Hammons <mark.hamm...@inaf.cnrs-gif.fr
> Yes, it's installed under /usr/lib/x86_64 or whatever the multilib path is
> debian. It seems files under this path are not accessible.
> I added LD_PRELOAD=/usr/lib/libtiff.so.5 to try to force the symlink to
> but it refused to load it. I think the mesos containerizer is preventing
> program from accessing anything in a directory under /usr/lib/ for some
> reason, as the same program runs fine in the same container running under
> On Monday, October 17, 2016 6:40:49 AM CEST Avinash Sridharan wrote:
> > Is the library part of the image that you are running? Also you might
> > to setup LD_LIBRARY_PATH in your env while launching the image so that
> > container process knows where to look for the shared object.
> > On Mon, Oct 17, 2016 at 5:21 AM, Mark Hammons <
> > > wrote:
> > >
> > > Hi all,
> > >
> > > I've been working with the mesos containerizer to handle my docker
> > > containers
> > > recently. I created a docker container that requires libtiff.so.5, and
> > > application within it runs well. But when I try to run it within the
> > > containerizer I get an error saying libtiff.so.5 doesn't exist.
> > >
> > > The application is being launched via java's process mechanism from
> > > a
> > > java thread in a custom java executor if that makes a difference.
> > >
> > > Any idea what could be causing this change in behavior? As you can see
> > > the
> > > attached log file, I check /usr/lib, and a symbolic link to
> > > /usr/lib/x86..../
> > > libtiff.so.5 exists in /usr/lib so the program should be able to find
> > > load
> > > that....
> > > ----
> > > Mark Edgar Hammons II | +33 06 03 69 56 56
> Mark Edgar Hammons II | +33 06 03 69 56 56
Avinash Sridharan, Mesosphere
+1 (323) 702 5245