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
Description: This is a digitally signed message part.