Running QuPath from a container

Hi there! (I’ll page @petebankhead already because I imagine he’ll be the one to answer this one.)

We’re in the process of offering all image analysis tools as Singularity containers so that they can be run directly in our clusters with access to fast storage - it’s been a mostly successful enterprise but we’ve run into problems with QuPath! I’m generating a super simple singularity container with the following recipe:

Bootstrap: docker
From: ubuntu:xenial

%runscript
    cd /qupath/QuPath
        ./QuPath

%post
    mkdir /qupath
    cd /qupath
    apt-get update
    apt-get install -y wget 
    wget https://github.com/qupath/qupath/releases/download/v0.1.2/QuPath-0.1.2.tar.gz
    tar xvvf QuPath-0.1.2.tar.gz
    rm QuPath-0.1.2.tar.gz

As you can see I’m going back to 0.1.2 just in case, and using Ubuntu 16.04 as suggested here. When I try to run this container, the only output I get is:

./qupath.sif 
15:24:47.704 [main] [INFO ] qupath.QuPath - Launching QuPath with args: 
QuPath Error invoking method.
QuPath Failed to launch JVM

Am I missing something? Do I need to install JRE/JDK separately? I looked around in the container for log files but couldn’t find on the QuPath folder. Any help appreciated!

Sure, I’ll answer… but disappointingly, I really have no idea :slight_smile:

It looks like the logger starts, but then gives up rather quickly. Am I right to think you want to start this up interactively, with the GUI?

This discussion might be vaguely useful; it depends on calling the .jar file and depending upon its classpath stored in the manifest*. I believe that can be used to launch QuPath interactively as well.

v0.1.2 still used javafxpackager, which has since been removed from the JDK and is in the process of being replaced with jpackage (due in JDK 14). Therefore launching v0.2.0 might prove to be different in some ways.

*- v0.2.0-mx has been broken in this regard, because I failed to adapt to a Gradle change… this commit should resolve the issue.

2 Likes

That’s correct! Most of the stuff we’ve tried (Fiji, CellProfiler, etc) worked pretty well and we’re at the point where people can use Fiji running in the cluster as if it was their personal computer, which is ideal from a user perspective.

This discussion might be vaguely useful; it depends on calling the .jar file and depending upon its classpath stored in the manifest*. I believe that can be used to launch QuPath interactively as well.

Thanks! I’ll go through it and see if it sheds some light on the issue.

v0.1.2 still used javafxpackager, which has since been removed from the JDK and is in the process of being replaced with jpackage (due in JDK 14). Therefore launching v0.2.0 might prove to be different in some ways.

I think I’ve tried 0.2.0-m8 as well, with similar results, but I’ll double-check.

*- v0.2.0-mx has been broken in this regard, because I failed to adapt to a Gradle change… this commit should resolve the issue.

Will also try that and report back!

2 Likes

Well, I just added default-jre as a package to be installed and it worked! Just the silliest possible solution. Thanks!

3 Likes

(as an update, this also works for 0.2.0m8)

3 Likes