As much as we would like our products to work flawlessly and intuitively, sometimes they don’t live up to this. The following information details some common errors you may some across or issues that we haven’t quite ironed out of our products.
This error might be seen when running workflows from a command prompt. It should not occur inside EPI2ME Desktop.
Our workflows use Docker) to simplify the distribution and running of bioinformatics software needed by the workflow. You need to install Docker (or another container runtime) on your system. Please consult with your system administrators on how to do this.
You may find some additional help on our Installation page.
This error might be seen when running a workflow that requires a GPU. Not many of our workflows require a GPU. See our Installation page for more information.
Exit status 137 is typically observed when the Nextflow process was killed for using too much memory. This may be the operating system invoking the out-of-memory (OOM) killer; or a cluster scheduler killing a job for exceeding its memory request.
Resolution of this issue will require knowledge of the failed process, which should be available in the Nextflow logging and the original memory requirement for that process.
For execution on a cluster Nextflow process selectors can be used to apply configuration to particular parts of our workflow.
To increase the memory for a process called my_process
, create a file (for example, named increase_memory.config
) with the following content:
process {withName:my_process {memory = “XX GB”}}
When invoking Nextflow with nextflow run
reference this extra configuration with -c increase_memory.config
.
If you continue to observe this error you may need to fine tune the memory value.
Local execution is a little more tricky.
It is likely that the number of processes allowed to run simultaneously given the users cpus
configuration may have allowed for multiple processes to exceed the RAM available on the device and invoke the system OOM killer, rather than a specific process exceeding its individual memory requirement.
The error maybe also simply stem from the latter.
In which case it is possible that the workflow simply cannot run on the system with the provided dataset.
To attempt a correction of the former issue you can use Nextflow process selectors to apply configuration to particular parts of our workflow. To decrease the number of simultaneous instances of “my_process” to 1, you can use the following config:
process {withName:my_process {maxForks = 1}}
If you are using the command line (or a script), create a file (for example, named resource.config
) and when invoking Nextflow with nextflow run
reference this extra configuration with -c resource.config
.
If you are using EPI2ME Desktop, you can instead specify additional Nextflow config options such as the example provided here in the “Extra configuration” options section at the bottom of the launch window.
The configuration you provide in that text box will be loaded into the workflow.
If this configuration works, you may wish to tune the value of maxForks to a value that works for your device.
This scary looking error indicates that Singularity failed to fetch part of an image (either from a remote repository, or the cache). The error should go away on rerunning the workflow. It is usually caused by a network error and should resolve itself. If you continue to see this error you may want to speak to your system administrator to check if anything may be blocking your access.
…failed to get checksum for docker://[…]: pinging docker registry returned: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io: no such host
The “no such host” here indicates that Singularity was unable to fetch part of a Docker image that we use to distribute bioinformatics software needed by the workflow because the registry containing our images could not be found. This error is usually caused by a network error and should resolve itself if you try to run the workflow again. If you continue to see this error you may want to speak to your system administrator to check if anything may be blocking your access such as firewalls, or if you need to configure a proxy.
Exit code 140 implies the process was sent the SIGUSR2
signal from the operating system.
It is typically observed when a user’s cluster is signalling that the job should wrap up because it is about to exceed a time or memory limit.
Users should speak to their system administrator to diagnose the reason that the job was terminated.
Information