OpenMOLE is fully working under OpenJDK 8 and above. OpenJDK is the recommended option. You can check which Java version
you're running by typing
in a console.
If you use the closed-source Oracle Java virtual machine (which is probably the case if you are working on Mac or
Windows), you have to install the Java Cryptography Extension (JCE) available at the bottom of this
in order for OpenMOLE to be
JCE is an archive containing a bunch of files that you should replace in the jre/lib/security
directory of your java installation. It enables strong cryptographic algorithms.
Another concern for Mac users
are the concurrent versions of Java that are often present on the same system. Mac
OS ships with a default Java 6 that is not suitable to execute OpenMOLE. You must install Java 8 or greater and
set the environment variable JAVA_HOME
to the install location on your machine (typically the directory
Old versions of OpenMOLE software and documentation are available here
. Due to a data loss in 2016, the versions from OpenMOLE 6 are available only.
When one of the SSH authentications you've added to OpenMOLE is marked as failed, you can try these few steps to identify the problems.
If you are using OpenMOLE in console mode, enable the FINE
level of logging in the console using:
If you are using the
authentication you might want to double check the user and
password you entered since one of them is more than likely incorrect.
SSH Keypair Authentication
In such a case, we'll have to investigate multiple options, as SSH public key authentications are sensitive to
several configuration parameters.
Public key authentication has usually a higher priority than password-based authentication when trying to
connect to a remote server. Thus, when you attempt an SSH connection to the the target environment, if your
client asks you to enter a password (please note that a passphrase is different from a password), then your
public key authentication is not taken into account.
SSH will skip your public key in case of bad configuration. The most common cases of badly configured keypairs
are the following:
- You haven't created an SSH keypair yet (using ssh-keygen). Private keys are usually stored in
~/.ssh/id_rsa or ~/.ssh/id_dsa, and should have a matching ~/.ssh/id_[rd]sa.pub next to them.
- Permissions of your ~/.ssh folder must be set to drwx—— (700 in octal). Also, too permissive home
directories (with write access given to the whole group for instance) might show problematic.
- A ~/.ssh/authorized_keys file must be present on the remote system. It should at least contain a line
matching the content of the ~/.ssh/id_[rd]sa.pub from your base system.
- You entered a passphrase when you generated your SSH keys and cannot remember it. In such a case, it might
be better to generate another keypair.
If you still could not solve your SSH authentication problems, another option is to recreate a public/private
keypair using the
shell command. Store it to a different file to avoid
overwriting the one already in place. You might also want to try a simple
authentication as explained in the SSH section
flag to your ssh
command will give a lot more details on the
communication between your client and the remote server. This will allow you to find out which authentication
is successful as well as the order in which the authentication modes are tried.
If you think OpenMOLE is crashed or stuck for some reason, here are a few things you can check from your system to decide whether it's just a temporary slow down or if the platform did actually crash.
Using tools from the Java Development Kit
A simple call to
from your command line will list all the instrumented JVMs on your system. If OpenMOLE is running, it is among these processes.
Now that you know OpenMOLE's process id, you can use
to print the eventual stack traces collected from OpenMOLE's threads. It's a bit low level but can at least give you enough material to thoroughly document your problem in the issue list or the mailing list.
The same procedure can be applied to the
running along OpenMOLE to manage the replica of the files copied to execution environments.
Inspecting the temporary folders
OpenMOLE automatically creates temporary folders on the machine it's running in order to handle various inputs and outputs.
If you have access to the machine running OpenMOLE, change to your OpenMOLE's preferences folder down to the following path: /home/user/.openmole/my_machine/.tmp
. List the content of this directory and change to the most recently created directory.
If you're using a remote environment, it should contain the tar archives used to populate new jobs on your remote computing environment, along with the input data files required by the task. The only presence of these files is a good indicator that OpenMOLE is functioning correctly and preparing the delegation of your workflow. Hardcore debuggers might want to go even deeper and extract the content of the tar archives to verify them, but this is out of scope.
However, touching on temporary file creation in OpenMOLE seamlessly leads us to our next entry...
OpenMOLE generates a fair amount of temporary files
in the .openmole/mymachine/.tmp
folder associated to your machine. Although these are deleted at the end of an execution, they can lead to a significant increase of the space occupied by your .openmole folder and of the number of files present in the same folder.
Because some systems place stringent limitations on these two quotas, you might want to move your .openmole
folder to a file system not restricted by quotas in order to run your OpenMOLE experiment successfully. The simplest way to do so is to create a destination folder in the unrestricted file system and then create a symbolic link name .openmole
in your home directory that points to this newly created folder. On a UNIX system, this procedure translates into the following commands.
# assumes /data is not restricted by quotas
cp -r ~/.openmole /data/openmole_data
rm -rf ~/.openmole
ln -s /data/openmole_data ~/.openmole
In order for this procedure to work, you'll want to ensure the target folder (/data/openmole
in the example) can be reached from all the machines running your OpenMOLE installation.
Moving your .openmole
to a different location is also strongly advised on remote execution hosts (typically clusters) on which you own a personal account
used with OpenMOLE. In the case of remote environments, the OpenMOLE runtime and the input files of your workflow will be copied to the .openmole
folder, again leading to problematic over quotas on these systems.
Combining samplings is straightforward in OpenMOLE, but can sometimes results in syntax errors a bit cryptic to new users.
Let's take the example of a combined sampling made of a file exploration sampling and an integer range exploration:
(input in (workDirectory / "../data/").files withName inputName) x
i in (1 to 10)
This combined sampling will generate the following error when compiling the workflow:
found : org.openmole.core.workflow.data.Prototype[Int]
OpenMOLE cannot identify the integer range the valid sampling it is. Simply wrapping the expression in parentheses
fixes the problem as shown in this correct version:
(input in (workDirectory / "../data/").files withName inputName) x
(i in (1 to 10))
CARE has recently encountered some compatibility issues with recent versions of the Linux kernel (>= 4.8). If you had
downloaded CARE before the release of OpenMOLE 6.0, you might be faced with this issue when trying to package new code.
The typical behaviour of this problem is to terminate CARE or your re-execution by a "signal 11" (Segmentation Fault)
message. The output will be similar to:
care info: pid 24238: terminated with signal 11
The easiest option to solve this problem is to download a fixed version from GitHub
This binary only works for 64 bits machines, which might not be the case of your workstation. Older versions of CARE are still available for different computer architecture from GitHub
. These versions require
environment variable to be set to 1 when running CARE. The packaging command line becomes:
PROOT_NO_SECCOMP=1 care -o foo.tgz.bin -r ~ my_app -input 42
You can also export this variable to your environment once and for all:
You'll have to do that in every terminal you're using unless you set this variable in your shell's startup file (~/.bashrc
if you're using bash
There is nothing to change in your OpenMOLE scripts, the good folks at OpenMOLE have everything under control ;)
For more information about this specific problem, you can join this discussion
On linux server the number of file a use can open is generally limited to 1024. OpenMOLE increase it to 4096 when on launch, but it doesn't seem to work on your system, you might want to understand why. To check the current of you system limit execute ulimit -a
in a terminal:
reuillon@docker-host1:~$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 64040
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 64040
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
In this example you can see the the nax number of open files is 1024. This is generally a soft limitation that can be overridden by the user. To do so execute ulimit -n 4096
before launching in the same terminal. You can check that you command had the expected effect using ulimit -a
. If is does't work it means that a hard limit has been set in the limits.conf
of your system. If you are administrator you can fix it by modifying the file /etc/security/limits.conf
, otherwise you should contact the system administrator and ask him/her kindly to unleash it.
For instance, if you try to use a standalone QGIS application, QGIS might try to access the display server (even when you run the application without a GUI).
This will definitely not work on a remote openmole instance (that probably does not have a display server).
The full error might look something like:
QXcbConnection: Could not connect to display
proot terminated with signal 6
Fortunately for you, we have a workaround.
Let's go back to our QGIS standalone application. It is a python application so we use CARE to embed it in a CARETask in openmole. The packaging would look like:
care -o myapp.tgz.bin python3 myapp.py param1 param2
The workaround uses xvfb
, a virtual framebuffer X server. The only thing you have to do is to run you command through xvfb. In our example, that would be:
care -o myapp.tgz.bin xvfb-run python3 myapp.py param1 param2
And that's it. After that, no connection to the display server will be attempted.
If you could not resolve your problems, feel free to post your problem on the mailing-list
If you think your problem is induced by a bug in OpenMOLE, please report the issue exhaustively on our GitHub page