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 <[email protected] > > 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 > > > > <[email protected]> > > > > > > > > > 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 < > > > > > > > > > > [email protected] > > > > > > > > > > > > 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 < > > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > 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 < > > > > > > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > 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 > > > > -- > > ---- > > Mark Edgar Hammons II | +33 06 03 69 56 56
-- ---- Mark Edgar Hammons II | +33 06 03 69 56 56
12: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,500000 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: error while loading shared libraries: libtiff.so.5: cannot open shared object file: No such file or directory 12:11:59.536 [Thread-38] ERROR IUWT_140926aR_t000_ch00.vtk.gz - unable to complete iuwt calculation... try: 1 for IUWT_140926aR_t000_ch00.vtk.gz 12:11:59.537 [Thread-115] 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.538 [Thread-38] ERROR IUWT_140926aR_t000_ch00.vtk.gz - unable to complete iuwt calculation... try: 2 for IUWT_140926aR_t000_ch00.vtk.gz 12:11:59.539 [Thread-122] 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.539 [Thread-38] ERROR IUWT_140926aR_t000_ch00.vtk.gz - unable to complete iuwt calculation... try: 3 for IUWT_140926aR_t000_ch00.vtk.gz
signature.asc
Description: This is a digitally signed message part.
