Re: Problems with shared libraries with mesos containerization....
Maybe just attach the docker file and make sure layers are available in
docker hub?
On Mon, Oct 17, 2016 at 9:07 AM Mark Hammons
wrote:
> Oh, the container image itself is very large. Do you have some place I can
> upload it to?
>
> On Monday, October 17, 2016 8:43:10 AM CEST Avinash Sridharan wrote:
> > Also would be good to see the env variables (LD_LIBRARY_PATH) being seen
> by
> > the container when you start it, just to make sure the env are getting
> set
> > correctly.
> >
> > On Mon, Oct 17, 2016 at 8:42 AM, Avinash Sridharan <
> avin...@mesosphere.io>
> >
> > wrote:
> > > Does look like the symlink exists:
> > > /usr/lib/libtiff.so.5
> > >
> > > I am assuming you have checked the realpath exists as well (that's why
> was
> > > asking for `ls -al`) ?
> > >
> > > Don't see that you have volume mounts that might obfuscate the path.
> Could
> > > you create a JIRA and if possible point give access to your docker
> image
> > > for us to try? Do mention the exact version of Mesos and the Distro you
> > > are
> > > trying to run this on.
> > >
> > > -Avinash
> > >
> > > On Mon, Oct 17, 2016 at 8:35 AM, Mark Hammons <
> > >
> > > mark.hamm...@inaf.cnrs-gif.fr> wrote:
> > >> No, it's a regular linux log. I've reattached it.
> > >>
> > >> On Monday, October 17, 2016 8:32:07 AM CEST Avinash Sridharan wrote:
> > >> > can't seem to open the attached logs, is it gzip?
> > >> >
> > >> > On Mon, Oct 17, 2016 at 8:14 AM, Mark Hammons <
> > >>
> > >> mark.hamm...@inaf.cnrs-gif.fr
> > >>
> > >> > > wrote:
> > >> > >
> > >> > > Adding LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu doesn't fix the
> > >>
> > >> error.
> > >>
> > >> > > On Monday, October 17, 2016 5:06:34 PM CEST Mark Hammons wrote:
> > >> > > > As I've shown in the original logs, the symbolic link
> libtiff.so.5
> > >>
> > >> is in
> > >>
> > >> > > > /usr/ lib. I used LD_PRELOAD just to try to force
> > >>
> > >> /usr/lib/libtiff.so.5
> > >>
> > >> > > to
> > >> > >
> > >> > > > be loaded since it wasn't for some reason.
> > >> > > >
> > >> > > > On Monday, October 17, 2016 8:03:34 AM CEST Avinash Sridharan
> wrote:
> > >> > > > > Can you prepend your command with `ls -al /usr/lib` and check
> in
> > >> > >
> > >> > > stdout if
> > >> > >
> > >> > > > > you are seeing the shared object? By the way why are you using
> > >> > >
> > >> > > LD_PRELOAD
> > >> > >
> > >> > > > > instead of LD_LIBRARY_PATH. LD_PRELOAD will force the linker
> to
> > >>
> > >> load
> > >>
> > >> > > your
> > >> > >
> > >> > > > > library before any other libraries. It's usually used to
> override
> > >> > >
> > >> > > system
> > >> > >
> > >> > > > > libraries so found a bit odd that you are using it here?
> > >> > > > >
> > >> > > > > On Mon, Oct 17, 2016 at 7:54 AM, Mark Hammons
> > >> > > > >
> > >> > > > >
> > >> > > > > > wrote:
> > >> > > > > >
> > >> > > > > > No, but even when I set LD_PRELOAD=/usr/lib/libtiff.so.5 for
> > >>
> > >> the
> > >>
> > >> > > process
> > >> > >
> > >> > > > > > environment it says it can't load /usr/lib/libtiff.so.5.
> > >> > > > > >
> > >> > > > > > On Monday, October 17, 2016 7:52:16 AM CEST Avinash
> Sridharan
> > >>
> > >> wrote:
> > >> > > > > > > Are you setting the env in the dockerfile?
> > >> > > > > > >
> > >> > > > > > > On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons <
> > >> > > > > >
> > >> > > > > > mark.hamm...@inaf.cnrs-gif.fr
> > >> > > > > >
> > >> > > > > > > > wrote:
> > >> > > > > > > >
> > >> > > > > > > > Here's the code I define my executor to mesos with:
> > >> > > > > > > > val iuwtURI = CommandInfo.URI.newBuilder().
> > >> > >
> > >> > > setValue("http://
> > >> > >
> > >> > > > > > ***/
> > >> > > > > >
> > >> > > > > > > > IUWT.tar.gz").setExtract(true).setCache(false).build()
> > >> > > > > > > >
> > >> > > > > > > > val iuwtjURI =
> > >> > > > > > > > CommandInfo.URI.newBuilder().setValue("http://
> > >> > > > > >
> > >> > > > > > ***/
> > >> > > > > >
> > >> > > > > > > > iuwtExecutor-assembly-0.1-
> > >> > > > > > > >
> SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> > >> > > > > > > >
> > >> > > > > > > > val iuwtExec = "java -jar
> > >> > > > > > > > iuwtExecutor-assembly-0.1-SNAPSHOT.jar
> > >> > > > > >
> > >> > > > > > -
> > >> > > > > >
> > >> > > > > > > > Xmx1024M -Xmx128M"
> > >> > > > > > > >
> > >> > > > > > > > val iuwtCommand =
> > >> > > > > > > >
> > >> > > > > > > > CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(
> > >> > >
> > >> > > List(iuwtjURI,
> > >> > >
> > >> > > > > > > > iuwtURI).asJava).setShell(true).build()
> > >> > > > > > > >
> > >> > > > > > > > val iuwtImageInfo =
> > >> > > > > > > >
> > >> > > > > > > > Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
> > >> > > > > > > > Image.Docker.newBuilder.setName("ubuntu-
> > >> > > > > > > > mesos:0.11-17102016-IUWT").build()).build()
> > >> > > > > > > >
> > >> > > > > > > > val iuwtContInfo =
> > >> > > > > > > >
> > >> > > > > > > > Container
Re: Problems with shared libraries with mesos containerization....
Oh, the container image itself is very large. Do you have some place I can
upload it to?
On Monday, October 17, 2016 8:43:10 AM CEST Avinash Sridharan wrote:
> Also would be good to see the env variables (LD_LIBRARY_PATH) being seen by
> the container when you start it, just to make sure the env are getting set
> correctly.
>
> On Mon, Oct 17, 2016 at 8:42 AM, Avinash Sridharan
>
> wrote:
> > Does look like the symlink exists:
> > /usr/lib/libtiff.so.5
> >
> > I am assuming you have checked the realpath exists as well (that's why was
> > asking for `ls -al`) ?
> >
> > Don't see that you have volume mounts that might obfuscate the path. Could
> > you create a JIRA and if possible point give access to your docker image
> > for us to try? Do mention the exact version of Mesos and the Distro you
> > are
> > trying to run this on.
> >
> > -Avinash
> >
> > On Mon, Oct 17, 2016 at 8:35 AM, Mark Hammons <
> >
> > mark.hamm...@inaf.cnrs-gif.fr> wrote:
> >> No, it's a regular linux log. I've reattached it.
> >>
> >> On Monday, October 17, 2016 8:32:07 AM CEST Avinash Sridharan wrote:
> >> > can't seem to open the attached logs, is it gzip?
> >> >
> >> > On Mon, Oct 17, 2016 at 8:14 AM, Mark Hammons <
> >>
> >> mark.hamm...@inaf.cnrs-gif.fr
> >>
> >> > > wrote:
> >> > >
> >> > > Adding LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu doesn't fix the
> >>
> >> error.
> >>
> >> > > On Monday, October 17, 2016 5:06:34 PM CEST Mark Hammons wrote:
> >> > > > As I've shown in the original logs, the symbolic link libtiff.so.5
> >>
> >> is in
> >>
> >> > > > /usr/ lib. I used LD_PRELOAD just to try to force
> >>
> >> /usr/lib/libtiff.so.5
> >>
> >> > > to
> >> > >
> >> > > > be loaded since it wasn't for some reason.
> >> > > >
> >> > > > On Monday, October 17, 2016 8:03:34 AM CEST Avinash Sridharan
wrote:
> >> > > > > Can you prepend your command with `ls -al /usr/lib` and check in
> >> > >
> >> > > stdout if
> >> > >
> >> > > > > you are seeing the shared object? By the way why are you using
> >> > >
> >> > > LD_PRELOAD
> >> > >
> >> > > > > instead of LD_LIBRARY_PATH. LD_PRELOAD will force the linker to
> >>
> >> load
> >>
> >> > > your
> >> > >
> >> > > > > library before any other libraries. It's usually used to override
> >> > >
> >> > > system
> >> > >
> >> > > > > libraries so found a bit odd that you are using it here?
> >> > > > >
> >> > > > > On Mon, Oct 17, 2016 at 7:54 AM, Mark Hammons
> >> > > > >
> >> > > > >
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > No, but even when I set LD_PRELOAD=/usr/lib/libtiff.so.5 for
> >>
> >> the
> >>
> >> > > process
> >> > >
> >> > > > > > environment it says it can't load /usr/lib/libtiff.so.5.
> >> > > > > >
> >> > > > > > On Monday, October 17, 2016 7:52:16 AM CEST Avinash Sridharan
> >>
> >> wrote:
> >> > > > > > > Are you setting the env in the dockerfile?
> >> > > > > > >
> >> > > > > > > On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons <
> >> > > > > >
> >> > > > > > mark.hamm...@inaf.cnrs-gif.fr
> >> > > > > >
> >> > > > > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > Here's the code I define my executor to mesos with:
> >> > > > > > > > val iuwtURI = CommandInfo.URI.newBuilder().
> >> > >
> >> > > setValue("http://
> >> > >
> >> > > > > > ***/
> >> > > > > >
> >> > > > > > > > IUWT.tar.gz").setExtract(true).setCache(false).build()
> >> > > > > > > >
> >> > > > > > > > val iuwtjURI =
> >> > > > > > > > CommandInfo.URI.newBuilder().setValue("http://
> >> > > > > >
> >> > > > > > ***/
> >> > > > > >
> >> > > > > > > > iuwtExecutor-assembly-0.1-
> >> > > > > > > > SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> >> > > > > > > >
> >> > > > > > > > val iuwtExec = "java -jar
> >> > > > > > > > iuwtExecutor-assembly-0.1-SNAPSHOT.jar
> >> > > > > >
> >> > > > > > -
> >> > > > > >
> >> > > > > > > > Xmx1024M -Xmx128M"
> >> > > > > > > >
> >> > > > > > > > val iuwtCommand =
> >> > > > > > > >
> >> > > > > > > > CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(
> >> > >
> >> > > List(iuwtjURI,
> >> > >
> >> > > > > > > > iuwtURI).asJava).setShell(true).build()
> >> > > > > > > >
> >> > > > > > > > val iuwtImageInfo =
> >> > > > > > > >
> >> > > > > > > > Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
> >> > > > > > > > Image.Docker.newBuilder.setName("ubuntu-
> >> > > > > > > > mesos:0.11-17102016-IUWT").build()).build()
> >> > > > > > > >
> >> > > > > > > > val iuwtContInfo =
> >> > > > > > > >
> >> > > > > > > > ContainerInfo.MesosInfo.newBuilder().setImage(
> >> > >
> >> > > iuwtImageInfo).build()
> >> > >
> >> > > > > > > > val iuwtContainer = ContainerInfo.newBuilder()
> >> > > > > > > >
> >> > > > > > > > .setMesos(iuwtContInfo)
> >> > > > > > > >
> >> > > > > > > > .setType(ContainerInfo.Type.MESOS)
> >> > > > > > > > .build()
> >> > > > > > > >
Re: Problems with shared libraries with mesos containerization....
I've created the issue and attached a log file with all the info you asked for
to it.
https://issues.apache.org/jira/browse/MESOS-6404
On Monday, October 17, 2016 8:42:13 AM CEST Avinash Sridharan wrote:
> Does look like the symlink exists:
> /usr/lib/libtiff.so.5
>
> I am assuming you have checked the realpath exists as well (that's why was
> asking for `ls -al`) ?
>
> Don't see that you have volume mounts that might obfuscate the path. Could
> you create a JIRA and if possible point give access to your docker image
> for us to try? Do mention the exact version of Mesos and the Distro you are
> trying to run this on.
>
> -Avinash
>
> On Mon, Oct 17, 2016 at 8:35 AM, Mark Hammons > wrote:
> >
> > No, it's a regular linux log. I've reattached it.
> >
> > On Monday, October 17, 2016 8:32:07 AM CEST Avinash Sridharan wrote:
> > > can't seem to open the attached logs, is it gzip?
> > >
> > > On Mon, Oct 17, 2016 at 8:14 AM, Mark Hammons <
> >
> > mark.hamm...@inaf.cnrs-gif.fr
> >
> > > > wrote:
> > > >
> > > > Adding LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu doesn't fix the
> >
> > error.
> >
> > > > On Monday, October 17, 2016 5:06:34 PM CEST Mark Hammons wrote:
> > > > > As I've shown in the original logs, the symbolic link libtiff.so.5
> >
> > is in
> >
> > > > > /usr/ lib. I used LD_PRELOAD just to try to force
> >
> > /usr/lib/libtiff.so.5
> >
> > > > to
> > > >
> > > > > be loaded since it wasn't for some reason.
> > > > >
> > > > > On Monday, October 17, 2016 8:03:34 AM CEST Avinash Sridharan wrote:
> > > > > > Can you prepend your command with `ls -al /usr/lib` and check in
> > > >
> > > > stdout if
> > > >
> > > > > > you are seeing the shared object? By the way why are you using
> > > >
> > > > LD_PRELOAD
> > > >
> > > > > > instead of LD_LIBRARY_PATH. LD_PRELOAD will force the linker to
> >
> > load
> >
> > > > your
> > > >
> > > > > > library before any other libraries. It's usually used to override
> > > >
> > > > system
> > > >
> > > > > > libraries so found a bit odd that you are using it here?
> > > > > >
> > > > > > On Mon, Oct 17, 2016 at 7:54 AM, Mark Hammons
> > > > > >
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > No, but even when I set LD_PRELOAD=/usr/lib/libtiff.so.5 for the
> > > >
> > > > process
> > > >
> > > > > > > environment it says it can't load /usr/lib/libtiff.so.5.
> > > > > > >
> > > > > > > On Monday, October 17, 2016 7:52:16 AM CEST Avinash Sridharan
> >
> > wrote:
> > > > > > > > Are you setting the env in the dockerfile?
> > > > > > > >
> > > > > > > > On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons <
> > > > > > >
> > > > > > > mark.hamm...@inaf.cnrs-gif.fr
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Here's the code I define my executor to mesos with:
> > > > > > > > > val iuwtURI = CommandInfo.URI.newBuilder().
> > > >
> > > > setValue("http://
> > > >
> > > > > > > ***/
> > > > > > >
> > > > > > > > > IUWT.tar.gz").setExtract(true).setCache(false).build()
> > > > > > > > >
> > > > > > > > > val iuwtjURI =
> > > > > > > > > CommandInfo.URI.newBuilder().setValue("http://
> > > > > > >
> > > > > > > ***/
> > > > > > >
> > > > > > > > > iuwtExecutor-assembly-0.1-
> > > > > > > > > SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> > > > > > > > >
> > > > > > > > > val iuwtExec = "java -jar
> > > > > > > > > iuwtExecutor-assembly-0.1-SNAPSHOT.jar
> > > > > > >
> > > > > > > -
> > > > > > >
> > > > > > > > > Xmx1024M -Xmx128M"
> > > > > > > > >
> > > > > > > > > val iuwtCommand =
> > > > > > > > >
> > > > > > > > > CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(
> > > >
> > > > List(iuwtjURI,
> > > >
> > > > > > > > > iuwtURI).asJava).setShell(true).build()
> > > > > > > > >
> > > > > > > > > val iuwtImageInfo =
> > > > > > > > >
> > > > > > > > > Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
> > > > > > > > > Image.Docker.newBuilder.setName("ubuntu-
> > > > > > > > > mesos:0.11-17102016-IUWT").build()).build()
> > > > > > > > >
> > > > > > > > > val iuwtContInfo =
> > > > > > > > >
> > > > > > > > > ContainerInfo.MesosInfo.newBuilder().setImage(
> > > >
> > > > iuwtImageInfo).build()
> > > >
> > > > > > > > > val iuwtContainer = ContainerInfo.newBuilder()
> > > > > > > > >
> > > > > > > > > .setMesos(iuwtContInfo)
> > > > > > > > >
> > > > > > > > > .setType(ContainerInfo.Type.MESOS)
> > > > > > > > > .build()
> > > > > > > > >
> > > > > > > > > val iuwtExecutor = ExecutorInfo.newBuilder()
> > > > > > > > >
> > > > > > > > > .setCommand(iuwtCommand)
> > > > > > > > > .setContainer(iuwtContainer)
> > > > > > > > > .setExecutorId(ExecutorID.
> > > >
> > > > newBuilder().setValue("iuw
> > > >
> > > > > > > > > t-
> > > > > > > >
Re: Problems with shared libraries with mesos containerization....
Also would be good to see the env variables (LD_LIBRARY_PATH) being seen by
the container when you start it, just to make sure the env are getting set
correctly.
On Mon, Oct 17, 2016 at 8:42 AM, Avinash Sridharan
wrote:
> Does look like the symlink exists:
> /usr/lib/libtiff.so.5
>
> I am assuming you have checked the realpath exists as well (that's why was
> asking for `ls -al`) ?
>
> Don't see that you have volume mounts that might obfuscate the path. Could
> you create a JIRA and if possible point give access to your docker image
> for us to try? Do mention the exact version of Mesos and the Distro you are
> trying to run this on.
>
> -Avinash
>
> On Mon, Oct 17, 2016 at 8:35 AM, Mark Hammons <
> mark.hamm...@inaf.cnrs-gif.fr> wrote:
>
>> No, it's a regular linux log. I've reattached it.
>>
>> On Monday, October 17, 2016 8:32:07 AM CEST Avinash Sridharan wrote:
>> > can't seem to open the attached logs, is it gzip?
>> >
>> > On Mon, Oct 17, 2016 at 8:14 AM, Mark Hammons <
>> mark.hamm...@inaf.cnrs-gif.fr
>> > > wrote:
>> > >
>> > > Adding LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu doesn't fix the
>> error.
>> > >
>> > > On Monday, October 17, 2016 5:06:34 PM CEST Mark Hammons wrote:
>> > > > As I've shown in the original logs, the symbolic link libtiff.so.5
>> is in
>> > > > /usr/ lib. I used LD_PRELOAD just to try to force
>> /usr/lib/libtiff.so.5
>> > >
>> > > to
>> > >
>> > > > be loaded since it wasn't for some reason.
>> > > >
>> > > > On Monday, October 17, 2016 8:03:34 AM CEST Avinash Sridharan wrote:
>> > > > > Can you prepend your command with `ls -al /usr/lib` and check in
>> > >
>> > > stdout if
>> > >
>> > > > > you are seeing the shared object? By the way why are you using
>> > >
>> > > LD_PRELOAD
>> > >
>> > > > > instead of LD_LIBRARY_PATH. LD_PRELOAD will force the linker to
>> load
>> > >
>> > > your
>> > >
>> > > > > library before any other libraries. It's usually used to override
>> > >
>> > > system
>> > >
>> > > > > libraries so found a bit odd that you are using it here?
>> > > > >
>> > > > > On Mon, Oct 17, 2016 at 7:54 AM, Mark Hammons
>> > > > >
>> > > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > No, but even when I set LD_PRELOAD=/usr/lib/libtiff.so.5 for
>> the
>> > >
>> > > process
>> > >
>> > > > > > environment it says it can't load /usr/lib/libtiff.so.5.
>> > > > > >
>> > > > > > On Monday, October 17, 2016 7:52:16 AM CEST Avinash Sridharan
>> wrote:
>> > > > > > > Are you setting the env in the dockerfile?
>> > > > > > >
>> > > > > > > On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons <
>> > > > > >
>> > > > > > mark.hamm...@inaf.cnrs-gif.fr
>> > > > > >
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > Here's the code I define my executor to mesos with:
>> > > > > > > > val iuwtURI = CommandInfo.URI.newBuilder().
>> > >
>> > > setValue("http://
>> > >
>> > > > > > ***/
>> > > > > >
>> > > > > > > > IUWT.tar.gz").setExtract(true).setCache(false).build()
>> > > > > > > >
>> > > > > > > > val iuwtjURI =
>> > > > > > > > CommandInfo.URI.newBuilder().setValue("http://
>> > > > > >
>> > > > > > ***/
>> > > > > >
>> > > > > > > > iuwtExecutor-assembly-0.1-
>> > > > > > > > SNAPSHOT.jar").setExecutable(false).setCache(false).build()
>> > > > > > > >
>> > > > > > > > val iuwtExec = "java -jar
>> > > > > > > > iuwtExecutor-assembly-0.1-SNAPSHOT.jar
>> > > > > >
>> > > > > > -
>> > > > > >
>> > > > > > > > Xmx1024M -Xmx128M"
>> > > > > > > >
>> > > > > > > > val iuwtCommand =
>> > > > > > > >
>> > > > > > > > CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(
>> > >
>> > > List(iuwtjURI,
>> > >
>> > > > > > > > iuwtURI).asJava).setShell(true).build()
>> > > > > > > >
>> > > > > > > > val iuwtImageInfo =
>> > > > > > > >
>> > > > > > > > Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
>> > > > > > > > Image.Docker.newBuilder.setName("ubuntu-
>> > > > > > > > mesos:0.11-17102016-IUWT").build()).build()
>> > > > > > > >
>> > > > > > > > val iuwtContInfo =
>> > > > > > > >
>> > > > > > > > ContainerInfo.MesosInfo.newBuilder().setImage(
>> > >
>> > > iuwtImageInfo).build()
>> > >
>> > > > > > > > val iuwtContainer = ContainerInfo.newBuilder()
>> > > > > > > >
>> > > > > > > > .setMesos(iuwtContInfo)
>> > > > > > > >
>> > > > > > > > .setType(ContainerInfo.Type.MESOS)
>> > > > > > > > .build()
>> > > > > > > >
>> > > > > > > > val iuwtExecutor = ExecutorInfo.newBuilder()
>> > > > > > > >
>> > > > > > > > .setCommand(iuwtCommand)
>> > > > > > > > .setContainer(iuwtContainer)
>> > > > > > > > .setExecutorId(ExecutorID.
>> > >
>> > > newBuilder().setValue("iuw
>> > >
>> > > > > > > > t-
>> > > > > > > >
>> > > > > > > > executor"))
>> > > > > > > >
>> > > > > > > > .setName("iuwt-executor").build()
>> > > > > > > >
>> > > > > > > > The ubuntu-mesos:0.11-17102016-IUWT is a l
Re: Problems with shared libraries with mesos containerization....
Does look like the symlink exists:
/usr/lib/libtiff.so.5
I am assuming you have checked the realpath exists as well (that's why was
asking for `ls -al`) ?
Don't see that you have volume mounts that might obfuscate the path. Could
you create a JIRA and if possible point give access to your docker image
for us to try? Do mention the exact version of Mesos and the Distro you are
trying to run this on.
-Avinash
On Mon, Oct 17, 2016 at 8:35 AM, Mark Hammons wrote:
> No, it's a regular linux log. I've reattached it.
>
> On Monday, October 17, 2016 8:32:07 AM CEST Avinash Sridharan wrote:
> > can't seem to open the attached logs, is it gzip?
> >
> > On Mon, Oct 17, 2016 at 8:14 AM, Mark Hammons <
> mark.hamm...@inaf.cnrs-gif.fr
> > > wrote:
> > >
> > > Adding LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu doesn't fix the
> error.
> > >
> > > On Monday, October 17, 2016 5:06:34 PM CEST Mark Hammons wrote:
> > > > As I've shown in the original logs, the symbolic link libtiff.so.5
> is in
> > > > /usr/ lib. I used LD_PRELOAD just to try to force
> /usr/lib/libtiff.so.5
> > >
> > > to
> > >
> > > > be loaded since it wasn't for some reason.
> > > >
> > > > On Monday, October 17, 2016 8:03:34 AM CEST Avinash Sridharan wrote:
> > > > > Can you prepend your command with `ls -al /usr/lib` and check in
> > >
> > > stdout if
> > >
> > > > > you are seeing the shared object? By the way why are you using
> > >
> > > LD_PRELOAD
> > >
> > > > > instead of LD_LIBRARY_PATH. LD_PRELOAD will force the linker to
> load
> > >
> > > your
> > >
> > > > > library before any other libraries. It's usually used to override
> > >
> > > system
> > >
> > > > > libraries so found a bit odd that you are using it here?
> > > > >
> > > > > On Mon, Oct 17, 2016 at 7:54 AM, Mark Hammons
> > > > >
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > No, but even when I set LD_PRELOAD=/usr/lib/libtiff.so.5 for the
> > >
> > > process
> > >
> > > > > > environment it says it can't load /usr/lib/libtiff.so.5.
> > > > > >
> > > > > > On Monday, October 17, 2016 7:52:16 AM CEST Avinash Sridharan
> wrote:
> > > > > > > Are you setting the env in the dockerfile?
> > > > > > >
> > > > > > > On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons <
> > > > > >
> > > > > > mark.hamm...@inaf.cnrs-gif.fr
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > Here's the code I define my executor to mesos with:
> > > > > > > > val iuwtURI = CommandInfo.URI.newBuilder().
> > >
> > > setValue("http://
> > >
> > > > > > ***/
> > > > > >
> > > > > > > > IUWT.tar.gz").setExtract(true).setCache(false).build()
> > > > > > > >
> > > > > > > > val iuwtjURI =
> > > > > > > > CommandInfo.URI.newBuilder().setValue("http://
> > > > > >
> > > > > > ***/
> > > > > >
> > > > > > > > iuwtExecutor-assembly-0.1-
> > > > > > > > SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> > > > > > > >
> > > > > > > > val iuwtExec = "java -jar
> > > > > > > > iuwtExecutor-assembly-0.1-SNAPSHOT.jar
> > > > > >
> > > > > > -
> > > > > >
> > > > > > > > Xmx1024M -Xmx128M"
> > > > > > > >
> > > > > > > > val iuwtCommand =
> > > > > > > >
> > > > > > > > CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(
> > >
> > > List(iuwtjURI,
> > >
> > > > > > > > iuwtURI).asJava).setShell(true).build()
> > > > > > > >
> > > > > > > > val iuwtImageInfo =
> > > > > > > >
> > > > > > > > Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
> > > > > > > > Image.Docker.newBuilder.setName("ubuntu-
> > > > > > > > mesos:0.11-17102016-IUWT").build()).build()
> > > > > > > >
> > > > > > > > val iuwtContInfo =
> > > > > > > >
> > > > > > > > ContainerInfo.MesosInfo.newBuilder().setImage(
> > >
> > > iuwtImageInfo).build()
> > >
> > > > > > > > val iuwtContainer = ContainerInfo.newBuilder()
> > > > > > > >
> > > > > > > > .setMesos(iuwtContInfo)
> > > > > > > >
> > > > > > > > .setType(ContainerInfo.Type.MESOS)
> > > > > > > > .build()
> > > > > > > >
> > > > > > > > val iuwtExecutor = ExecutorInfo.newBuilder()
> > > > > > > >
> > > > > > > > .setCommand(iuwtCommand)
> > > > > > > > .setContainer(iuwtContainer)
> > > > > > > > .setExecutorId(ExecutorID.
> > >
> > > newBuilder().setValue("iuw
> > >
> > > > > > > > t-
> > > > > > > >
> > > > > > > > executor"))
> > > > > > > >
> > > > > > > > .setName("iuwt-executor").build()
> > > > > > > >
> > > > > > > > The ubuntu-mesos:0.11-17102016-IUWT is a locally hosted
> docker
> > > > > > > > image.
> > > > > > > > IUWT is
> > > > > > > > the program I'm trying to run, and it runs perfectly fine in
> the
> > > > > > > > aforementioned docker container when running on docker. The
> > > > > >
> > > > > > libtiff.so.5
> > > > > >
> > > > > > > > problem only manifests when I'm using mesos' containerizer.
> > > > > > > >
> > > > > > > > On Monday, October 17, 2016
Re: Problems with shared libraries with mesos containerization....
can't seem to open the attached logs, is it gzip?
On Mon, Oct 17, 2016 at 8:14 AM, Mark Hammons wrote:
> Adding LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu doesn't fix the error.
>
> On Monday, October 17, 2016 5:06:34 PM CEST Mark Hammons wrote:
> > As I've shown in the original logs, the symbolic link libtiff.so.5 is in
> > /usr/ lib. I used LD_PRELOAD just to try to force /usr/lib/libtiff.so.5
> to
> > be loaded since it wasn't for some reason.
> >
> > On Monday, October 17, 2016 8:03:34 AM CEST Avinash Sridharan wrote:
> > > Can you prepend your command with `ls -al /usr/lib` and check in
> stdout if
> > > you are seeing the shared object? By the way why are you using
> LD_PRELOAD
> > > instead of LD_LIBRARY_PATH. LD_PRELOAD will force the linker to load
> your
> > > library before any other libraries. It's usually used to override
> system
> > > libraries so found a bit odd that you are using it here?
> > >
> > > On Mon, Oct 17, 2016 at 7:54 AM, Mark Hammons
> > >
> > > > wrote:
> > > >
> > > > No, but even when I set LD_PRELOAD=/usr/lib/libtiff.so.5 for the
> process
> > > > environment it says it can't load /usr/lib/libtiff.so.5.
> > > >
> > > > On Monday, October 17, 2016 7:52:16 AM CEST Avinash Sridharan wrote:
> > > > > Are you setting the env in the dockerfile?
> > > > >
> > > > > On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons <
> > > >
> > > > mark.hamm...@inaf.cnrs-gif.fr
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > Here's the code I define my executor to mesos with:
> > > > > > val iuwtURI = CommandInfo.URI.newBuilder().
> setValue("http://
> > > >
> > > > ***/
> > > >
> > > > > > IUWT.tar.gz").setExtract(true).setCache(false).build()
> > > > > >
> > > > > > val iuwtjURI =
> > > > > > CommandInfo.URI.newBuilder().setValue("http://
> > > >
> > > > ***/
> > > >
> > > > > > iuwtExecutor-assembly-0.1-
> > > > > > SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> > > > > >
> > > > > > val iuwtExec = "java -jar
> > > > > > iuwtExecutor-assembly-0.1-SNAPSHOT.jar
> > > >
> > > > -
> > > >
> > > > > > Xmx1024M -Xmx128M"
> > > > > >
> > > > > > val iuwtCommand =
> > > > > >
> > > > > > CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(
> List(iuwtjURI,
> > > > > > iuwtURI).asJava).setShell(true).build()
> > > > > >
> > > > > > val iuwtImageInfo =
> > > > > >
> > > > > > Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
> > > > > > Image.Docker.newBuilder.setName("ubuntu-
> > > > > > mesos:0.11-17102016-IUWT").build()).build()
> > > > > >
> > > > > > val iuwtContInfo =
> > > > > >
> > > > > > ContainerInfo.MesosInfo.newBuilder().setImage(
> iuwtImageInfo).build()
> > > > > >
> > > > > > val iuwtContainer = ContainerInfo.newBuilder()
> > > > > >
> > > > > > .setMesos(iuwtContInfo)
> > > > > >
> > > > > > .setType(ContainerInfo.Type.MESOS)
> > > > > > .build()
> > > > > >
> > > > > > val iuwtExecutor = ExecutorInfo.newBuilder()
> > > > > >
> > > > > > .setCommand(iuwtCommand)
> > > > > > .setContainer(iuwtContainer)
> > > > > > .setExecutorId(ExecutorID.
> newBuilder().setValue("iuw
> > > > > > t-
> > > > > >
> > > > > > executor"))
> > > > > >
> > > > > > .setName("iuwt-executor").build()
> > > > > >
> > > > > > The ubuntu-mesos:0.11-17102016-IUWT is a locally hosted docker
> > > > > > image.
> > > > > > IUWT is
> > > > > > the program I'm trying to run, and it runs perfectly fine in the
> > > > > > aforementioned docker container when running on docker. The
> > > >
> > > > libtiff.so.5
> > > >
> > > > > > problem only manifests when I'm using mesos' containerizer.
> > > > > >
> > > > > > On Monday, October 17, 2016 6:52:17 AM CEST Avinash Sridharan
> wrote:
> > > > > > > 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
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > Yes, it's installed under /usr/lib/x86_64 or whatever the
> > > > > > > > multilib
> > > > > >
> > > > > > path is
> > > > > >
> > > > > > > > in
> > > > > > > > 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
> > > > > >
> > > > > > > > load
> > > > > > > > but it refused to load it. I think the mesos containerizer is
> > > > > >
> > > > > > preventing
> > > > > >
> > > > > > > > the
> > > > > > > > program from accessing anything in a directory under
> /usr/lib/
> > > > > > > > for
> > > > > > > > some
> > > > > > > > reason, as the same program runs fine in the same container
> > > > > > > > r
Re: Problems with shared libraries with mesos containerization....
No, it's a regular linux log. I've reattached it.
On Monday, October 17, 2016 8:32:07 AM CEST Avinash Sridharan wrote:
> can't seem to open the attached logs, is it gzip?
>
> On Mon, Oct 17, 2016 at 8:14 AM, Mark Hammons > wrote:
> >
> > Adding LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu doesn't fix the error.
> >
> > On Monday, October 17, 2016 5:06:34 PM CEST Mark Hammons wrote:
> > > As I've shown in the original logs, the symbolic link libtiff.so.5 is in
> > > /usr/ lib. I used LD_PRELOAD just to try to force /usr/lib/libtiff.so.5
> >
> > to
> >
> > > be loaded since it wasn't for some reason.
> > >
> > > On Monday, October 17, 2016 8:03:34 AM CEST Avinash Sridharan wrote:
> > > > Can you prepend your command with `ls -al /usr/lib` and check in
> >
> > stdout if
> >
> > > > you are seeing the shared object? By the way why are you using
> >
> > LD_PRELOAD
> >
> > > > instead of LD_LIBRARY_PATH. LD_PRELOAD will force the linker to load
> >
> > your
> >
> > > > library before any other libraries. It's usually used to override
> >
> > system
> >
> > > > libraries so found a bit odd that you are using it here?
> > > >
> > > > On Mon, Oct 17, 2016 at 7:54 AM, Mark Hammons
> > > >
> > > >
> > > > > wrote:
> > > > >
> > > > > No, but even when I set LD_PRELOAD=/usr/lib/libtiff.so.5 for the
> >
> > process
> >
> > > > > environment it says it can't load /usr/lib/libtiff.so.5.
> > > > >
> > > > > On Monday, October 17, 2016 7:52:16 AM CEST Avinash Sridharan wrote:
> > > > > > Are you setting the env in the dockerfile?
> > > > > >
> > > > > > On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons <
> > > > >
> > > > > mark.hamm...@inaf.cnrs-gif.fr
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > Here's the code I define my executor to mesos with:
> > > > > > > val iuwtURI = CommandInfo.URI.newBuilder().
> >
> > setValue("http://
> >
> > > > > ***/
> > > > >
> > > > > > > IUWT.tar.gz").setExtract(true).setCache(false).build()
> > > > > > >
> > > > > > > val iuwtjURI =
> > > > > > > CommandInfo.URI.newBuilder().setValue("http://
> > > > >
> > > > > ***/
> > > > >
> > > > > > > iuwtExecutor-assembly-0.1-
> > > > > > > SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> > > > > > >
> > > > > > > val iuwtExec = "java -jar
> > > > > > > iuwtExecutor-assembly-0.1-SNAPSHOT.jar
> > > > >
> > > > > -
> > > > >
> > > > > > > Xmx1024M -Xmx128M"
> > > > > > >
> > > > > > > val iuwtCommand =
> > > > > > >
> > > > > > > CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(
> >
> > List(iuwtjURI,
> >
> > > > > > > iuwtURI).asJava).setShell(true).build()
> > > > > > >
> > > > > > > val iuwtImageInfo =
> > > > > > >
> > > > > > > Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
> > > > > > > Image.Docker.newBuilder.setName("ubuntu-
> > > > > > > mesos:0.11-17102016-IUWT").build()).build()
> > > > > > >
> > > > > > > val iuwtContInfo =
> > > > > > >
> > > > > > > ContainerInfo.MesosInfo.newBuilder().setImage(
> >
> > iuwtImageInfo).build()
> >
> > > > > > > val iuwtContainer = ContainerInfo.newBuilder()
> > > > > > >
> > > > > > > .setMesos(iuwtContInfo)
> > > > > > >
> > > > > > > .setType(ContainerInfo.Type.MESOS)
> > > > > > > .build()
> > > > > > >
> > > > > > > val iuwtExecutor = ExecutorInfo.newBuilder()
> > > > > > >
> > > > > > > .setCommand(iuwtCommand)
> > > > > > > .setContainer(iuwtContainer)
> > > > > > > .setExecutorId(ExecutorID.
> >
> > newBuilder().setValue("iuw
> >
> > > > > > > t-
> > > > > > >
> > > > > > > executor"))
> > > > > > >
> > > > > > > .setName("iuwt-executor").build()
> > > > > > >
> > > > > > > The ubuntu-mesos:0.11-17102016-IUWT is a locally hosted docker
> > > > > > > image.
> > > > > > > IUWT is
> > > > > > > the program I'm trying to run, and it runs perfectly fine in the
> > > > > > > aforementioned docker container when running on docker. The
> > > > >
> > > > > libtiff.so.5
> > > > >
> > > > > > > problem only manifests when I'm using mesos' containerizer.
> > > > > > >
> > > > > > > On Monday, October 17, 2016 6:52:17 AM CEST Avinash Sridharan
> >
> > wrote:
> > > > > > > > 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
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Yes, it's installed under /usr/lib/x86_64 or whatever the
> > > > > > > > > multilib
> > > > > > >
> > > > > > > path is
> > > > > > >
> > > > > > > > > in
> > > > > > > > > debian. It seems files under this path are n
Re: Problems with shared libraries with mesos containerization....
Adding LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu doesn't fix the error.
On Monday, October 17, 2016 5:06:34 PM CEST Mark Hammons wrote:
> As I've shown in the original logs, the symbolic link libtiff.so.5 is in
> /usr/ lib. I used LD_PRELOAD just to try to force /usr/lib/libtiff.so.5 to
> be loaded since it wasn't for some reason.
>
> On Monday, October 17, 2016 8:03:34 AM CEST Avinash Sridharan wrote:
> > Can you prepend your command with `ls -al /usr/lib` and check in stdout if
> > you are seeing the shared object? By the way why are you using LD_PRELOAD
> > instead of LD_LIBRARY_PATH. LD_PRELOAD will force the linker to load your
> > library before any other libraries. It's usually used to override system
> > libraries so found a bit odd that you are using it here?
> >
> > On Mon, Oct 17, 2016 at 7:54 AM, Mark Hammons
> >
> > > wrote:
> > >
> > > No, but even when I set LD_PRELOAD=/usr/lib/libtiff.so.5 for the process
> > > environment it says it can't load /usr/lib/libtiff.so.5.
> > >
> > > On Monday, October 17, 2016 7:52:16 AM CEST Avinash Sridharan wrote:
> > > > Are you setting the env in the dockerfile?
> > > >
> > > > On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons <
> > >
> > > mark.hamm...@inaf.cnrs-gif.fr
> > >
> > > > > wrote:
> > > > >
> > > > > Here's the code I define my executor to mesos with:
> > > > > val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://
> > >
> > > ***/
> > >
> > > > > IUWT.tar.gz").setExtract(true).setCache(false).build()
> > > > >
> > > > > val iuwtjURI =
> > > > > CommandInfo.URI.newBuilder().setValue("http://
> > >
> > > ***/
> > >
> > > > > iuwtExecutor-assembly-0.1-
> > > > > SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> > > > >
> > > > > val iuwtExec = "java -jar
> > > > > iuwtExecutor-assembly-0.1-SNAPSHOT.jar
> > >
> > > -
> > >
> > > > > Xmx1024M -Xmx128M"
> > > > >
> > > > > val iuwtCommand =
> > > > >
> > > > > CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
> > > > > iuwtURI).asJava).setShell(true).build()
> > > > >
> > > > > val iuwtImageInfo =
> > > > >
> > > > > Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
> > > > > Image.Docker.newBuilder.setName("ubuntu-
> > > > > mesos:0.11-17102016-IUWT").build()).build()
> > > > >
> > > > > val iuwtContInfo =
> > > > >
> > > > > ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
> > > > >
> > > > > val iuwtContainer = ContainerInfo.newBuilder()
> > > > >
> > > > > .setMesos(iuwtContInfo)
> > > > >
> > > > > .setType(ContainerInfo.Type.MESOS)
> > > > > .build()
> > > > >
> > > > > val iuwtExecutor = ExecutorInfo.newBuilder()
> > > > >
> > > > > .setCommand(iuwtCommand)
> > > > > .setContainer(iuwtContainer)
> > > > > .setExecutorId(ExecutorID.newBuilder().setValue("iuw
> > > > > t-
> > > > >
> > > > > executor"))
> > > > >
> > > > > .setName("iuwt-executor").build()
> > > > >
> > > > > The ubuntu-mesos:0.11-17102016-IUWT is a locally hosted docker
> > > > > image.
> > > > > IUWT is
> > > > > the program I'm trying to run, and it runs perfectly fine in the
> > > > > aforementioned docker container when running on docker. The
> > >
> > > libtiff.so.5
> > >
> > > > > problem only manifests when I'm using mesos' containerizer.
> > > > >
> > > > > On Monday, October 17, 2016 6:52:17 AM CEST Avinash Sridharan wrote:
> > > > > > 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
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > Yes, it's installed under /usr/lib/x86_64 or whatever the
> > > > > > > multilib
> > > > >
> > > > > path is
> > > > >
> > > > > > > in
> > > > > > > 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
> > > > >
> > > > > > > load
> > > > > > > but it refused to load it. I think the mesos containerizer is
> > > > >
> > > > > preventing
> > > > >
> > > > > > > the
> > > > > > > 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
> > > > >
> > > > > > > docker.
> > > > > > >
> > > > > > > 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
> > > > > > >
> > >
Re: Problems with shared libraries with mesos containerization....
As I've shown in the original logs, the symbolic link libtiff.so.5 is in /usr/
lib. I used LD_PRELOAD just to try to force /usr/lib/libtiff.so.5 to be loaded
since it wasn't for some reason.
On Monday, October 17, 2016 8:03:34 AM CEST Avinash Sridharan wrote:
> Can you prepend your command with `ls -al /usr/lib` and check in stdout if
> you are seeing the shared object? By the way why are you using LD_PRELOAD
> instead of LD_LIBRARY_PATH. LD_PRELOAD will force the linker to load your
> library before any other libraries. It's usually used to override system
> libraries so found a bit odd that you are using it here?
>
> On Mon, Oct 17, 2016 at 7:54 AM, Mark Hammons > wrote:
> >
> > No, but even when I set LD_PRELOAD=/usr/lib/libtiff.so.5 for the process
> > environment it says it can't load /usr/lib/libtiff.so.5.
> >
> > On Monday, October 17, 2016 7:52:16 AM CEST Avinash Sridharan wrote:
> > > Are you setting the env in the dockerfile?
> > >
> > > On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons <
> >
> > mark.hamm...@inaf.cnrs-gif.fr
> >
> > > > wrote:
> > > >
> > > > Here's the code I define my executor to mesos with:
> > > > val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://
> >
> > ***/
> >
> > > > IUWT.tar.gz").setExtract(true).setCache(false).build()
> > > >
> > > > val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://
> >
> > ***/
> >
> > > > iuwtExecutor-assembly-0.1-
> > > > SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> > > >
> > > > val iuwtExec = "java -jar
> > > > iuwtExecutor-assembly-0.1-SNAPSHOT.jar
> >
> > -
> >
> > > > Xmx1024M -Xmx128M"
> > > >
> > > > val iuwtCommand =
> > > >
> > > > CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
> > > > iuwtURI).asJava).setShell(true).build()
> > > >
> > > > val iuwtImageInfo =
> > > >
> > > > Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
> > > > Image.Docker.newBuilder.setName("ubuntu-
> > > > mesos:0.11-17102016-IUWT").build()).build()
> > > >
> > > > val iuwtContInfo =
> > > >
> > > > ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
> > > >
> > > > val iuwtContainer = ContainerInfo.newBuilder()
> > > >
> > > > .setMesos(iuwtContInfo)
> > > >
> > > > .setType(ContainerInfo.Type.MESOS)
> > > > .build()
> > > >
> > > > val iuwtExecutor = ExecutorInfo.newBuilder()
> > > >
> > > > .setCommand(iuwtCommand)
> > > > .setContainer(iuwtContainer)
> > > > .setExecutorId(ExecutorID.newBuilder().setValue("iuwt-
> > > >
> > > > executor"))
> > > >
> > > > .setName("iuwt-executor").build()
> > > >
> > > > The ubuntu-mesos:0.11-17102016-IUWT is a locally hosted docker image.
> > > > IUWT is
> > > > the program I'm trying to run, and it runs perfectly fine in the
> > > > aforementioned docker container when running on docker. The
> >
> > libtiff.so.5
> >
> > > > problem only manifests when I'm using mesos' containerizer.
> > > >
> > > > On Monday, October 17, 2016 6:52:17 AM CEST Avinash Sridharan wrote:
> > > > > 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
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > Yes, it's installed under /usr/lib/x86_64 or whatever the multilib
> > > >
> > > > path is
> > > >
> > > > > > in
> > > > > > 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
> > > >
> > > > > > load
> > > > > > but it refused to load it. I think the mesos containerizer is
> > > >
> > > > preventing
> > > >
> > > > > > the
> > > > > > 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
> > > >
> > > > > > docker.
> > > > > >
> > > > > > 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
> > > > > >
> > > > > > need
> > > > > >
> > > > > > > to setup LD_LIBRARY_PATH in your env while launching the image
> > > > > > > so
> > > >
> > > > that
> > > >
> > > > > > the
> > > > > >
> > > > > > > container process knows where to look for the shared object.
> > > > > > >
> > > > > > > On Mon, Oct 17, 2016 at 5:21 AM, Mark Hammons <
> > > > > >
> > > > > > mark.hamm...@inaf.cnrs-gif.fr
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > I've been working
Re: Problems with shared libraries with mesos containerization....
Can you prepend your command with `ls -al /usr/lib` and check in stdout if
you are seeing the shared object? By the way why are you using LD_PRELOAD
instead of LD_LIBRARY_PATH. LD_PRELOAD will force the linker to load your
library before any other libraries. It's usually used to override system
libraries so found a bit odd that you are using it here?
On Mon, Oct 17, 2016 at 7:54 AM, Mark Hammons wrote:
> No, but even when I set LD_PRELOAD=/usr/lib/libtiff.so.5 for the process
> environment it says it can't load /usr/lib/libtiff.so.5.
>
> On Monday, October 17, 2016 7:52:16 AM CEST Avinash Sridharan wrote:
> > Are you setting the env in the dockerfile?
> >
> > On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons <
> mark.hamm...@inaf.cnrs-gif.fr
> > > wrote:
> > >
> > > Here's the code I define my executor to mesos with:
> > > val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://
> ***/
> > >
> > > IUWT.tar.gz").setExtract(true).setCache(false).build()
> > >
> > > val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://
> ***/
> > >
> > > iuwtExecutor-assembly-0.1-
> > > SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> > >
> > > val iuwtExec = "java -jar iuwtExecutor-assembly-0.1-SNAPSHOT.jar
> -
> > >
> > > Xmx1024M -Xmx128M"
> > >
> > > val iuwtCommand =
> > >
> > > CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
> > > iuwtURI).asJava).setShell(true).build()
> > >
> > > val iuwtImageInfo =
> > >
> > > Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
> > > Image.Docker.newBuilder.setName("ubuntu-
> > > mesos:0.11-17102016-IUWT").build()).build()
> > >
> > > val iuwtContInfo =
> > >
> > > ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
> > >
> > > val iuwtContainer = ContainerInfo.newBuilder()
> > >
> > > .setMesos(iuwtContInfo)
> > >
> > > .setType(ContainerInfo.Type.MESOS)
> > > .build()
> > >
> > > val iuwtExecutor = ExecutorInfo.newBuilder()
> > >
> > > .setCommand(iuwtCommand)
> > > .setContainer(iuwtContainer)
> > > .setExecutorId(ExecutorID.newBuilder().setValue("iuwt-
> > >
> > > executor"))
> > >
> > > .setName("iuwt-executor").build()
> > >
> > > The ubuntu-mesos:0.11-17102016-IUWT is a locally hosted docker image.
> > > IUWT is
> > > the program I'm trying to run, and it runs perfectly fine in the
> > > aforementioned docker container when running on docker. The
> libtiff.so.5
> > > problem only manifests when I'm using mesos' containerizer.
> > >
> > > On Monday, October 17, 2016 6:52:17 AM CEST Avinash Sridharan wrote:
> > > > 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
> > >
> > > > > wrote:
> > > > >
> > > > > Yes, it's installed under /usr/lib/x86_64 or whatever the multilib
> > >
> > > path is
> > >
> > > > > in
> > > > > 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
> > >
> > > > > load
> > > > > but it refused to load it. I think the mesos containerizer is
> > >
> > > preventing
> > >
> > > > > the
> > > > > 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
> > >
> > > > > docker.
> > > > >
> > > > > 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
> > > > >
> > > > > need
> > > > >
> > > > > > to setup LD_LIBRARY_PATH in your env while launching the image so
> > >
> > > that
> > >
> > > > > the
> > > > >
> > > > > > container process knows where to look for the shared object.
> > > > > >
> > > > > > On Mon, Oct 17, 2016 at 5:21 AM, Mark Hammons <
> > > > >
> > > > > mark.hamm...@inaf.cnrs-gif.fr
> > > > >
> > > > > > > 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
> > >
> > > > > the
> > > > >
> > > > > > > application within it runs well. But when I try to run it
> within
> > >
> > > the
> > >
> > > > > mesos
> > > > >
> > > > > > > containerizer I get an error saying libtiff.so.5 doesn't exist.
> > > > > > >
> > > > > > > The application is being launched via java's process mechanism
> > > > > > > from
> > > > >
> > > > > inside
> > > > >
> > > > > > > a
> > > > > > > java thread in a custom java executor if that makes a
> difference.
> > > > > > >
> > > > > > > Any idea
Re: Problems with shared libraries with mesos containerization....
Are you setting the env in the dockerfile?
On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons wrote:
> Here's the code I define my executor to mesos with:
>
> val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://***/
> IUWT.tar.gz").setExtract(true).setCache(false).build()
>
> val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://***/
> iuwtExecutor-assembly-0.1-
> SNAPSHOT.jar").setExecutable(false).setCache(false).build()
>
> val iuwtExec = "java -jar iuwtExecutor-assembly-0.1-SNAPSHOT.jar -
> Xmx1024M -Xmx128M"
>
> val iuwtCommand =
> CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
> iuwtURI).asJava).setShell(true).build()
>
> val iuwtImageInfo =
> Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
> Image.Docker.newBuilder.setName("ubuntu-
> mesos:0.11-17102016-IUWT").build()).build()
>
> val iuwtContInfo =
> ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
>
>
> val iuwtContainer = ContainerInfo.newBuilder()
> .setMesos(iuwtContInfo)
> .setType(ContainerInfo.Type.MESOS)
> .build()
>
> val iuwtExecutor = ExecutorInfo.newBuilder()
> .setCommand(iuwtCommand)
> .setContainer(iuwtContainer)
> .setExecutorId(ExecutorID.newBuilder().setValue("iuwt-
> executor"))
> .setName("iuwt-executor").build()
>
> The ubuntu-mesos:0.11-17102016-IUWT is a locally hosted docker image.
> IUWT is
> the program I'm trying to run, and it runs perfectly fine in the
> aforementioned docker container when running on docker. The libtiff.so.5
> problem only manifests when I'm using mesos' containerizer.
>
> On Monday, October 17, 2016 6:52:17 AM CEST Avinash Sridharan wrote:
> > 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
> > > wrote:
> > >
> > > Yes, it's installed under /usr/lib/x86_64 or whatever the multilib
> path is
> > > in
> > > 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
> > > load
> > > but it refused to load it. I think the mesos containerizer is
> preventing
> > > the
> > > 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
> > > docker.
> > >
> > > 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
> > >
> > > need
> > >
> > > > to setup LD_LIBRARY_PATH in your env while launching the image so
> that
> > >
> > > the
> > >
> > > > container process knows where to look for the shared object.
> > > >
> > > > On Mon, Oct 17, 2016 at 5:21 AM, Mark Hammons <
> > >
> > > mark.hamm...@inaf.cnrs-gif.fr
> > >
> > > > > 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
> > >
> > > the
> > >
> > > > > application within it runs well. But when I try to run it within
> the
> > >
> > > mesos
> > >
> > > > > containerizer I get an error saying libtiff.so.5 doesn't exist.
> > > > >
> > > > > The application is being launched via java's process mechanism from
> > >
> > > inside
> > >
> > > > > 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
> > >
> > > in
> > >
> > > > > 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
> > >
> > > and
> > >
> > > > > load
> > > > > that
> > > > >
> > > > > Mark Edgar Hammons II | +33 06 03 69 56 56
> > >
> > > --
> > >
> > > 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
Re: Problems with shared libraries with mesos containerization....
No, but even when I set LD_PRELOAD=/usr/lib/libtiff.so.5 for the process
environment it says it can't load /usr/lib/libtiff.so.5.
On Monday, October 17, 2016 7:52:16 AM CEST Avinash Sridharan wrote:
> Are you setting the env in the dockerfile?
>
> On Mon, Oct 17, 2016 at 6:58 AM, Mark Hammons > wrote:
> >
> > Here's the code I define my executor to mesos with:
> > val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://***/
> >
> > IUWT.tar.gz").setExtract(true).setCache(false).build()
> >
> > val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://***/
> >
> > iuwtExecutor-assembly-0.1-
> > SNAPSHOT.jar").setExecutable(false).setCache(false).build()
> >
> > val iuwtExec = "java -jar iuwtExecutor-assembly-0.1-SNAPSHOT.jar -
> >
> > Xmx1024M -Xmx128M"
> >
> > val iuwtCommand =
> >
> > CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
> > iuwtURI).asJava).setShell(true).build()
> >
> > val iuwtImageInfo =
> >
> > Image.newBuilder().setType(Image.Type.DOCKER).setDocker(
> > Image.Docker.newBuilder.setName("ubuntu-
> > mesos:0.11-17102016-IUWT").build()).build()
> >
> > val iuwtContInfo =
> >
> > ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
> >
> > val iuwtContainer = ContainerInfo.newBuilder()
> >
> > .setMesos(iuwtContInfo)
> >
> > .setType(ContainerInfo.Type.MESOS)
> > .build()
> >
> > val iuwtExecutor = ExecutorInfo.newBuilder()
> >
> > .setCommand(iuwtCommand)
> > .setContainer(iuwtContainer)
> > .setExecutorId(ExecutorID.newBuilder().setValue("iuwt-
> >
> > executor"))
> >
> > .setName("iuwt-executor").build()
> >
> > The ubuntu-mesos:0.11-17102016-IUWT is a locally hosted docker image.
> > IUWT is
> > the program I'm trying to run, and it runs perfectly fine in the
> > aforementioned docker container when running on docker. The libtiff.so.5
> > problem only manifests when I'm using mesos' containerizer.
> >
> > On Monday, October 17, 2016 6:52:17 AM CEST Avinash Sridharan wrote:
> > > 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
> >
> > > > wrote:
> > > >
> > > > Yes, it's installed under /usr/lib/x86_64 or whatever the multilib
> >
> > path is
> >
> > > > in
> > > > 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
> >
> > > > load
> > > > but it refused to load it. I think the mesos containerizer is
> >
> > preventing
> >
> > > > the
> > > > 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
> >
> > > > docker.
> > > >
> > > > 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
> > > >
> > > > need
> > > >
> > > > > to setup LD_LIBRARY_PATH in your env while launching the image so
> >
> > that
> >
> > > > the
> > > >
> > > > > container process knows where to look for the shared object.
> > > > >
> > > > > On Mon, Oct 17, 2016 at 5:21 AM, Mark Hammons <
> > > >
> > > > mark.hamm...@inaf.cnrs-gif.fr
> > > >
> > > > > > 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
> >
> > > > the
> > > >
> > > > > > application within it runs well. But when I try to run it within
> >
> > the
> >
> > > > mesos
> > > >
> > > > > > containerizer I get an error saying libtiff.so.5 doesn't exist.
> > > > > >
> > > > > > The application is being launched via java's process mechanism
> > > > > > from
> > > >
> > > > inside
> > > >
> > > > > > 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
> >
> > > > in
> > > >
> > > > > > 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
> >
> > > > and
> > > >
> > > > > > load
> > > > > > that
> > > > > >
> > > > > > Mark Edgar Hammons II | +33 06 03 69 56 56
> > > >
> > > > --
> > > >
> > > > Mark Edgar Hammons II | +33 06 03 69 56 56
> >
> > --
> >
> > Mark Edgar Hammons II | +33 06 03 69 56 56
--
Mark Edgar Hammons II | +33 06 03 69 56 56
signature.asc
D
Re: Problems with shared libraries with mesos containerization....
Here's the code I define my executor to mesos with:
val iuwtURI = CommandInfo.URI.newBuilder().setValue("http://***/
IUWT.tar.gz").setExtract(true).setCache(false).build()
val iuwtjURI = CommandInfo.URI.newBuilder().setValue("http://***/
iuwtExecutor-assembly-0.1-
SNAPSHOT.jar").setExecutable(false).setCache(false).build()
val iuwtExec = "java -jar iuwtExecutor-assembly-0.1-SNAPSHOT.jar -
Xmx1024M -Xmx128M"
val iuwtCommand =
CommandInfo.newBuilder.setValue(iuwtExec).addAllUris(List(iuwtjURI,
iuwtURI).asJava).setShell(true).build()
val iuwtImageInfo =
Image.newBuilder().setType(Image.Type.DOCKER).setDocker(Image.Docker.newBuilder.setName("ubuntu-
mesos:0.11-17102016-IUWT").build()).build()
val iuwtContInfo =
ContainerInfo.MesosInfo.newBuilder().setImage(iuwtImageInfo).build()
val iuwtContainer = ContainerInfo.newBuilder()
.setMesos(iuwtContInfo)
.setType(ContainerInfo.Type.MESOS)
.build()
val iuwtExecutor = ExecutorInfo.newBuilder()
.setCommand(iuwtCommand)
.setContainer(iuwtContainer)
.setExecutorId(ExecutorID.newBuilder().setValue("iuwt-executor"))
.setName("iuwt-executor").build()
The ubuntu-mesos:0.11-17102016-IUWT is a locally hosted docker image. IUWT is
the program I'm trying to run, and it runs perfectly fine in the
aforementioned docker container when running on docker. The libtiff.so.5
problem only manifests when I'm using mesos' containerizer.
On Monday, October 17, 2016 6:52:17 AM CEST Avinash Sridharan wrote:
> 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 > wrote:
> >
> > Yes, it's installed under /usr/lib/x86_64 or whatever the multilib path is
> > in
> > 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
> > load
> > but it refused to load it. I think the mesos containerizer is preventing
> > the
> > 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
> > docker.
> >
> > 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
> >
> > need
> >
> > > to setup LD_LIBRARY_PATH in your env while launching the image so that
> >
> > the
> >
> > > container process knows where to look for the shared object.
> > >
> > > On Mon, Oct 17, 2016 at 5:21 AM, Mark Hammons <
> >
> > mark.hamm...@inaf.cnrs-gif.fr
> >
> > > > 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
> >
> > the
> >
> > > > application within it runs well. But when I try to run it within the
> >
> > mesos
> >
> > > > containerizer I get an error saying libtiff.so.5 doesn't exist.
> > > >
> > > > The application is being launched via java's process mechanism from
> >
> > inside
> >
> > > > 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
> >
> > in
> >
> > > > 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
> >
> > and
> >
> > > > load
> > > > that
> > > >
> > > > Mark Edgar Hammons II | +33 06 03 69 56 56
> >
> > --
> >
> > Mark Edgar Hammons II | +33 06 03 69 56 56
--
Mark Edgar Hammons II | +33 06 03 69 56 56
signature.asc
Description: This is a digitally signed message part.
Re: Problems with shared libraries with mesos containerization....
Inside the container's file system. I was hoping that as far as my application is concerned my host file system doesn't exist. On Monday, October 17, 2016 6:52:17 AM CEST Avinash Sridharan wrote: > 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 > wrote: > > > > Yes, it's installed under /usr/lib/x86_64 or whatever the multilib path is > > in > > 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 > > load > > but it refused to load it. I think the mesos containerizer is preventing > > the > > 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 > > docker. > > > > 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 > > > > need > > > > > to setup LD_LIBRARY_PATH in your env while launching the image so that > > > > the > > > > > container process knows where to look for the shared object. > > > > > > On Mon, Oct 17, 2016 at 5:21 AM, Mark Hammons < > > > > mark.hamm...@inaf.cnrs-gif.fr > > > > > > 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 > > > > the > > > > > > application within it runs well. But when I try to run it within the > > > > mesos > > > > > > containerizer I get an error saying libtiff.so.5 doesn't exist. > > > > > > > > The application is being launched via java's process mechanism from > > > > inside > > > > > > 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 > > > > in > > > > > > 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 > > > > and > > > > > > load > > > > that > > > > > > > > Mark Edgar Hammons II | +33 06 03 69 56 56 > > > > -- > > > > Mark Edgar Hammons II | +33 06 03 69 56 56 -- Mark Edgar Hammons II | +33 06 03 69 56 56 signature.asc Description: This is a digitally signed message part.
Re: Problems with shared libraries with mesos containerization....
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 wrote: > Yes, it's installed under /usr/lib/x86_64 or whatever the multilib path is > in > 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 > load > but it refused to load it. I think the mesos containerizer is preventing > the > 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 > docker. > > 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 > need > > to setup LD_LIBRARY_PATH in your env while launching the image so that > the > > container process knows where to look for the shared object. > > > > On Mon, Oct 17, 2016 at 5:21 AM, Mark Hammons < > mark.hamm...@inaf.cnrs-gif.fr > > > 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 > the > > > application within it runs well. But when I try to run it within the > mesos > > > containerizer I get an error saying libtiff.so.5 doesn't exist. > > > > > > The application is being launched via java's process mechanism from > inside > > > 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 > in > > > 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 > and > > > 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
Re: Problems with shared libraries with mesos containerization....
Yes, it's installed under /usr/lib/x86_64 or whatever the multilib path is in 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 load but it refused to load it. I think the mesos containerizer is preventing the 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 docker. 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 need > to setup LD_LIBRARY_PATH in your env while launching the image so that the > 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 the > > application within it runs well. But when I try to run it within the mesos > > containerizer I get an error saying libtiff.so.5 doesn't exist. > > > > The application is being launched via java's process mechanism from inside > > 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 in > > 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 and > > load > > that > > > > Mark Edgar Hammons II | +33 06 03 69 56 56 -- Mark Edgar Hammons II | +33 06 03 69 56 56 signature.asc Description: This is a digitally signed message part.
Re: Problems with shared libraries with mesos containerization....
Is the library part of the image that you are running? Also you might need to setup LD_LIBRARY_PATH in your env while launching the image so that the 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 the > application within it runs well. But when I try to run it within the mesos > containerizer I get an error saying libtiff.so.5 doesn't exist. > > The application is being launched via java's process mechanism from inside > 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 in > 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 and > load > that > > Mark Edgar Hammons II | +33 06 03 69 56 56 -- Avinash Sridharan, Mesosphere +1 (323) 702 5245
Problems with shared libraries with mesos containerization....
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 the application within it runs well. But when I try to run it within the mesos containerizer I get an error saying libtiff.so.5 doesn't exist. The application is being launched via java's process mechanism from inside 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 in 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 and load that Mark Edgar Hammons II | +33 06 03 69 56 5612:11:58.278 [Thread-38] INFO IUWT_140926aR_t000_ch00.vtk.gz - inputFile,/bioemerg/groups/rawdata/Im2014/Trim3/140926aR/VTK/140926aR_t000_ch00.vtk.gz iter,50 fpr,0.25 rst,50 Jm,0 JM,7 outputPath,/bioemerg/groups/processdata/WKF/Im2014/Trim3/140926aR/ALGO_560/RUN_9787/output logPath,/bioemerg/groups/processdata/WKF/Im2014/Trim3/140926aR/ALGO_560/RUN_9787/__stdStreams__ 12:11:58.753 [Thread-38] DEBUG eu.bioemergences.mesos.VTK - beginning VTK construction. arguments: /bioemerg/groups/rawdata/Im2014/Trim3/140926aR/VTK/140926aR_t000_ch00.vtk.gz, irods, # vtk DataFile Version 3.0 # Embryomics Properties BINARY DATASET STRUCTURED_POINTS DIMENSIONS 512 512 131 SPACING 0.692 0.692 0.896 ORIGIN 0.000 0.000 0.000 POINT_DATA 34340864 COLOR_SCALARS scalars 1 , 34340864, (512,512,131), (0.692,0.692,0.896), 34341066 12:11:58.803 [Thread-38] INFO IUWT_140926aR_t000_ch00.vtk.gz - /etc/ld.so.conf? true 12:11:58.804 [Thread-38] INFO IUWT_140926aR_t000_ch00.vtk.gz - /usr/lib/.../usr/lib/dbus-1.0 /usr/lib/libmpichfort.so.12 /usr/lib/libcr_omit.so /usr/lib/libhpdf-2.2.1.so /usr/lib/libopen-rte.so.12.0.2 /usr/lib/libmgl-mpi.so /usr/lib/tar /usr/lib/libmpi_usempi_ignore_tkr.so.6 /usr/lib/libmesos.so /usr/lib/libcr.la /usr/lib/mime /usr/lib/libmgl-fltk.so.7.4.0 /usr/lib/tmpfiles.d /usr/lib/libtiff.so.5 /usr/lib/libmgl-wx.so.7.4.0 /usr/lib/libmca_common_verbs.so.7.0.0 /usr/lib/libmgl-glut.so.7.4.0 /usr/lib/libmgl-wnd.so.7.4.0 /usr/lib/libmgl-qt5.so /usr/lib/libmca_common_sm.so.4.0.4 /usr/lib/dpkg /usr/lib/libmfhdf.so.0 /usr/lib/libmpichcxx.so.12 /usr/lib/libopen-pal.so.13 /usr/lib/libmpi_mpifh.so.12.0.0 /usr/lib/libmca_common_sm.so.4 /usr/lib/libibverbs.so.1 /usr/lib/libcr_omit.so.0.5.5 /usr/lib/libcr_run.so.0.5.5 /usr/lib/libmpi.so.12.0.2 /usr/lib/X11 /usr/lib/libmgl-mpi.a /usr/lib/mpich /usr/lib/binfmt.d /usr/lib/libmpicxx.so /usr/lib/libmgl-wnd.so /usr/lib/libompitrace.so.0.0.0 /usr/lib/libmgl-qt.so.7.4.0 /usr/lib/libmpi_cxx.so.1 /usr/lib/libmpi_cxx.so.1.1.3 /usr/lib/locale /usr/lib/gnupg /usr/lib/libmpi_usempi_ignore_tkr.so.6.1.0 /usr/lib/libmgl-fltk.a /usr/lib/libopen-pal.so.13.0.2 /usr/lib/libmpif90.so /usr/lib/libcr_omit.so.0 /usr/lib/systemd /usr/lib/libcr.so /usr/lib/libmca_common_verbs.so.7 /usr/lib/openssh /usr/lib/libmesos-1.0.1.so /usr/lib/libmgl-wnd.a /usr/lib/libmgl-qt5.a /usr/lib/openmpi /usr/lib/libmgl.so /usr/lib/libmgl-wx.a /usr/lib/libmpif77.so /usr/lib/libmgl-qt5.so.7.4.0 /usr/lib/ssl /usr/lib/libmpi.so.12 /usr/lib/libcr.so.0.5.5 /usr/lib/os-release /usr/lib/libmpi_usempif08.so.11.1.0 /usr/lib/libdf.so.0 /usr/lib/libcr_run.so.0 /usr/lib/libmgl-fltk.so /usr/lib/python3 /usr/lib/libcr_run.la /usr/lib/libmgl-qt.a /usr/lib/emacsen-common /usr/lib/libmgl.so.7.4.0 /usr/lib/modules-load.d /usr/lib/libompitrace.so.0 /usr/lib/libcr.so.0 /usr/lib/insserv /usr/lib/python2.7 /usr/lib/glib-networking /usr/lib/libmgl-glut.a /usr/lib/dconf /usr/lib/apt /usr/lib/libopen-rte.so.12 /usr/lib/libcr_run.so /usr/lib/libmpi++.so /usr/lib/policykit-1 /usr/lib/libmpi_usempif08.so.11 /usr/lib/libmpi_mpifh.so.12 /usr/lib/libmpich.so.12 /usr/lib/libmgl-glut.so /usr/lib/libdf.so.0.0.0 /usr/lib/git-core /usr/lib/notification-daemon /usr/lib/libmgl-qt.so /usr/lib/libmpifort.so /usr/lib/libmgl.a /usr/lib/libmgl-wx.so /usr/lib/libcr_omit.la /usr/lib/sasl2 /usr/lib/x86_64-linux-gnu /usr/lib/jvm /usr/lib/libmpi.so /usr/lib/libibverbs.so.1.0.0 /usr/lib/libmgl-mpi.so.7.4.0 /usr/lib/at-spi2-core /usr/lib/libmfhdf.so.0.0.0 /usr/lib/colord /usr/lib/gcc 12:11:58.831 [Thread-38] INFO IUWT_140926aR_t000_ch00.vtk.gz - downloading input vtk from /bioemerg/groups/rawdata/Im2014/Trim3/140926aR/VTK/140926aR_t000_ch00.vtk.gz 12:11:59.528 [Thread-38] INFO IUWT_140926aR_t000_ch00.vtk.gz - checking file size: 5895718453248 12:11:59.528 [Thread-38] INFO IUWT_140926aR_t000_ch00.vtk.gz - beginning processing... 12:11:59.530 [Thread-103] ERROR IUWT_140926aR_t000_ch00.vtk.gz - IUWT/build/exec: error while loading shared libraries: libtiff.so.5: cannot open shared object file: No such file or directory 12:11:59.530 [Thread-38] ERROR IUWT_140926aR_t000_ch00.vtk.gz - unable to complete iuwt calculation... try: 0 for IUWT_140926aR_t000_ch00.vtk.gz 12:11:59.531 [Thread-109] ERROR IUWT_140926aR_t000_ch00.vtk.gz - IUWT/build/exec: er
