From 5e22ddd4fa7df4e15de60b015e3420fc946bbcbe Mon Sep 17 00:00:00 2001 From: Patrik Smeds Date: Tue, 1 Apr 2025 09:14:55 -0400 Subject: [PATCH 1/2] first draft for instructions how to run planemo and submit jobs to a slurm cluster --- docs/slurm_cluster_workflows.rst | 265 +++++++++++++++++++++++++++++++ 1 file changed, 265 insertions(+) create mode 100644 docs/slurm_cluster_workflows.rst diff --git a/docs/slurm_cluster_workflows.rst b/docs/slurm_cluster_workflows.rst new file mode 100644 index 000000000..e8d75b4ca --- /dev/null +++ b/docs/slurm_cluster_workflows.rst @@ -0,0 +1,265 @@ +Galaxy Workflows on a local cluster +============================================ + +Some users may be unable to upload data to publicly available Galaxy +instances due to legal restrictions. While they might have access to +locally hosted cluster systems, these systems may not allow hosting +web servers or have the necessary personnel to maintain a Galaxy +instance. In such cases, Planemo provides a solution by spinning up +a temporary local Galaxy instance, allowing users to execute +workflows. Jobs can then be run on the same server or submitted to a +workload manager, such as slurm. + +Software requirements +--------------------- +Planemo +~~~~~~~~~~~~~~~~~~ + +If planemo isn't available on the system, it can be easily installed +in a virtual environment. +:: + + python -m venv planemo_venv + . planemo_venv/bin/activate + pip install planemo + +Additional instructions to install planemo can be found at +`install planemo `__. + +DRMAA library +~~~~~~~~~~~~~~~~~~ +To run workflows on a cluster, Galaxy requires access to DRMAA libraries, +which allow communication with the workload manager. +If your system does not include DRMAA libraries, you will need to compile +them manually. For SLURM, the source code and compilation instructions +are available on GitHub:: `slurm-drmaa `__. + +:: + + # Download and extract source code + wget https://github.com/natefoo/slurm-drmaa/releases/download/1.1.4/slurm-drmaa-1.1.4.tar.gz + tar -xvzf slurm-drmaa-1.1.4.tar.gz + cd slurm-drmaa-1.1.4 && mkdir dist + + # Configure build + ./autogen.sh + ./configure --prefix=${PWD}/dist + + # Compile and install + make + make install + + # print path to library + LIBDRMAA=`ls ${PWD}/dist/lib/libdrmaa.so` + echo "Library: ${LIBDRMAA}" + + +Tool dependencies +~~~~~~~~~~~~~~~~~~ +To run a tool/workflow on a server or cluster, the required tools must +be available on the system. If they are not, Galaxy can manage dependencies +using Conda, Docker or Singularity. While Conda is an option, Docker or +Singularity is recommended for its greater reliability. One of the following +environments need to be available on the system: + +- Complete set of used tools installed in the system +- Conda +- Docker +- Singularity + + +Database +------------------ +Galaxy uses a database to track jobs and their statuses, with SQLite as the default +option. However, when running more complex workflows, errors can occur if multiple +jobs are updated simultaneously, leading to database locking and causing the workflow +to terminate prematurely. This issue can be easily avoided by switching to a +PostgreSQL database instead of SQLite. If the user doesn't have access to a PostgreSQL +database, planemo can spin up a temporary PostgreSQL instance using Singularity by adding +a ``--database_type postgres_singularity`` to the run comman. + +Configuration +------------------ +To apply the settings needed for running a workflow/tool you need to configure a job_conf.yaml +file, some of the settings can be applied using the command line, for example: + +- use temporary postgres database: ``--database_type postgres_singularity`` +- use containers for tools: ``--biocontainers`` + +Job configuration +~~~~~~~~~~~~~~~~~~ + +The job configuration file must specify the path to the DRMAA library and define basic +SLURM settings using the `native_specification` tag. For convenience, we will also +configure the Singularity options. + +:: + + runners: + local: + load: galaxy.jobs.runners.local:LocalJobRunner + # modify the number of threads working on local jobs here + # workers: 4 + slurm: + load: galaxy.jobs.runners.slurm:SlurmJobRunner + # modify below to specify a specific drmaa shared library for slurm + drmaa_library_path: /scratch/10171/smeds/run_planemo_using_drmaa/slurm-drmaa-1.1.4/dist/lib/libdrmaa.so + + execution: + default: slurm + environments: + local: + runner: local + singularity_enabled: true + singularity_cmd: singularity + singularity_volumes: $defaults + slurm: + runner: slurm + native_specification: "-p icx,skx --time=02:00:00 --nodes=1" + singularity_enabled: true + singularity_cmd: singularity + singularity_volumes: $defaults + require_container: true + tools: + - class: local + environment: local + + +If your system has a different setup, Galaxy provides `galaxy-job-config-init `__ +, a tool for generating job_config files tailored to various environments and workload managers. +More examples of how to setup the job_configuration file can be found at `job_conf.sample.yaml `__. + +Running +------------------ +Planemo can be run with many different settings, depending on the user's needs. This example +will be running a workflow using slurm and SQLite or PostgreSQL. + +Example workflow +~~~~~~~~~~~~~~~~~~ +Here is the ``job_conf.yaml`` file for the example workflow. It has been modified +to handle two specific tools differently, as they require Conda to run. + +:: + + runners: + local: + load: galaxy.jobs.runners.local:LocalJobRunner + # modify the number of threads working on local jobs here + # workers: 4 + slurm: + load: galaxy.jobs.runners.slurm:SlurmJobRunner + # modify below to specify a specific drmaa shared library for slurm + drmaa_library_path: PATH_TO_LIBRARY/slurm-drmaa-1.1.4/dist/lib/libdrmaa.so + + execution: + default: slurm + environments: + local: + runner: local + singularity_enabled: true + singularity_cmd: singularity + singularity_volumes: $defaults + slurm: + runner: slurm + native_specification: "-p QUEUE_NAME --time=02:00:00 --nodes=1" + singularity_enabled: true + singularity_cmd: singularity + singularity_volumes: $defaults + require_container: true + slurm_conda: + runner: slurm + native_specification: "-p QUEUE_NAME --time=02:00:00 --nodes=1" + conda_enabled: true + require_container: false + tools: + - id: cat1 + environment: slurm_conda + - id: random_lines1 + environment: slurm_conda + - class: local + environment: local + + +Run using the default SQLite database +:: + + git clone https://github.com/usegalaxy-eu/workflow-testing.git + cd workflow-testing/example3 + python3.9 -m venv planemo_venv && source planemo_venv/bin/activate + pip install planemo + # Make sure the temporary folder is shared between servers. + planemo run tutorial.ga tutorial-job.yml \ + --download_outputs \ + --output_directory . \ + --output_json output.json \ + --job_config_file job_config.yaml + +Run using a temporary PostgreSQL database +:: + + git clone https://github.com/usegalaxy-eu/workflow-testing.git + cd workflow-testing/example3 + python3.9 -m venv venv && source venv/bin/activate + pip install planemo + # Make sure that the singulariy command is available + # Make sure the temporary folder is shared between servers. + planemo run tutorial.ga tutorial-job.yml \ + --download_outputs \ + --output_directory . \ + --output_json output.json \ + --job_config_file job_config.yaml \ + --database_type postgres_singularity + + +Troubleshooting +------------------ + +**Temp direcory not shared between nodes** + +Galaxy uses a temporary directory when creating and running jobs. +This directory must be accessible to both the server that creates +the job and the compute node that executes it. If this folder is +not shared, local jobs will succeed, while those submitted to a +separate compute node will fail. To resolve this issue, configure +a shared folder as the temporary directory. + +:: + + TMPDIR=PATH_TO_SHARED_TEMPORARY_FOLDER planemo run ... + +**Locked database** + +While running jobs, Galaxy tracks their status using a database. +The default database is SQLite, which may encounter issues when +handling a high number of concurrent jobs. In such cases, you may see errors like this: + + +:: + + cursor.execute(statement, parameters) + sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) database is locked + [SQL: SELECT kombu_queue.id AS kombu_queue_id, kombu_queue.name AS kombu_queue_name + FROM kombu_queue + WHERE kombu_queue.name = ? + LIMIT ? OFFSET ?] + +The solution is to switch to a more robust database, such as PostgreSQL. + +**Multiple galaxy instances** + +When you run ``planemo run`` a temporary Galaxy instance is created and +in some cases that instance my not be properly shut down. This can cause +the following error: + +:: + + bioblend.ConnectionError: Unexpected HTTP status code: 500: Internal Server Error: make sure that you don't already have a running galaxy instance. + +You will be able to see if instances are still running using the following commands: + +:: + + # Find running galaxy instances + ps aux | grep galaxy + # Find running planemo commands + ps aux | grep planemo From 8f5c2813bdf21e136dc86f3187ebf7731895dd18 Mon Sep 17 00:00:00 2001 From: Patrik Smeds Date: Wed, 11 Jun 2025 21:27:34 +0200 Subject: [PATCH 2/2] Updated instructions, now including tpv instructions. --- docs/_running_slurm.rst | 265 +++++++++++++++++++++++++++++++ docs/running.rst | 3 +- docs/slurm_cluster_workflows.rst | 265 ------------------------------- 3 files changed, 267 insertions(+), 266 deletions(-) create mode 100644 docs/_running_slurm.rst delete mode 100644 docs/slurm_cluster_workflows.rst diff --git a/docs/_running_slurm.rst b/docs/_running_slurm.rst new file mode 100644 index 000000000..3f9998e84 --- /dev/null +++ b/docs/_running_slurm.rst @@ -0,0 +1,265 @@ +Running workflow on a server or cluster +============================================ + +In some situations, users may be unable to upload data to public Galaxy instances due to legal or policy restrictions. +Even if they have access to local cluster systems, these environments often do not permit hosting web servers or lack +dedicated personnel to maintain a Galaxy instance. +Planemo addresses this challenge by enabling users to launch a temporary local Galaxy instance, allowing workflow +execution without the need for a permanent server setup. +Jobs can be executed directly on the server or submitted to a workload manager such as Slurm. + +This guide explains how to run a workflow: + 1. On a standalone server + 2. On a Slurm cluster using DRMAA + + +Requirements +--------------------- + +- planemo: install instructions are available at :doc:`readme` +- DRMAA library +- Tools dependencies +- Database (optional) + +DRMAA library +~~~~~~~~~~~~~~~~~~ +To enable Galaxy to submit jobs to a cluster via Slurm, you need the DRMAA +(Distributed Resource Management Application API) library, which provides a standard interface +for job submission. If your system does not already have the DRMAA library installed, you must +compile it manually. For Slurm, the recommended implementation is +`slurm-drmaa `__. + +Follow these steps to download and build the DRMAA library for Slurm: + +:: + + # Download and extract source code + wget https://github.com/natefoo/slurm-drmaa/releases/download/1.1.4/slurm-drmaa-1.1.4.tar.gz + tar -xvzf slurm-drmaa-1.1.4.tar.gz + cd slurm-drmaa-1.1.4 && mkdir dist + + # Configure build + ./autogen.sh + ./configure --prefix=${PWD}/dist + + # Compile and install + make + make install + + # print path to library + LIBDRMAA=`ls ${PWD}/dist/lib/libdrmaa.so` + echo "Library: ${LIBDRMAA}" + + +Tool dependencies +~~~~~~~~~~~~~~~~~~ +To run a tool/workflow on a server or cluster, the required tools must +be available on the system. Galaxy can manage dependencies +using Conda, Docker or Singularity. While Conda is an option, Docker or +Singularity is recommended for its greater reliability. One of the following +environments need to be available on the system: + +- Conda +- Docker +- Singularity + + +Database +~~~~~~~~~~~~~~~~~~ +Galaxy tracks jobs and their statuses using a database, with SQLite as the default option. +However, when running complex workflows, SQLite can encounter issues if multiple jobs attempt +to update the database simultaneously. This can lead to database locking and premature workflow +termination. + +To prevent these issues, it's recommended to use a PostgreSQL database instead of SQLite. If a +PostgreSQL database isn't readily available, Planemo can launch a temporary PostgreSQL instance +using Singularity by adding the ``--database_type postgres_singularity`` to the run command. + + +Running on workflow +------------------ +Planemo can be configured in many ways to suit different user needs. In this guide, we'll demonstrate +how to run a workflow on both a local laptop/server and a SLURM cluster, using the same example workflow +introduced in `the basic `_ + +Laptop/server +~~~~~~~~~~~~~~~~~~ +:: + + planemo run tutorial.ga tutorial-job.yml \ + --download_outputs \ + --output_directory . \ + --output_json output.json \ + --biocontainers + +This command runs the workflow locally and attempts to resolve tool dependencies using containers. If the +workflow completes successfully, the output files will be downloaded to the current directory. + +Slurm +~~~~~~~~~~~~~~~~~~ + +To run the workflow on a SLURM cluster, you’ll need to configure the ``job_config.yaml`` file to set up a job +runner that uses the DRMAA library for job submission. + + +**job_config.yaml** +:: + + runners: + local: + load: galaxy.jobs.runners.local:LocalJobRunner + slurm: + load: galaxy.jobs.runners.slurm:SlurmJobRunner + drmaa_library_path: PATH/slurm-drmaa-1.1.4/dist/lib/libdrmaa.so + + execution: + default: slurm + environments: + local: + runner: local + slurm: + runner: slurm + native_specification: "-p PARTITION_NAME --time=02:00:00 --nodes=1" + singularity_enabled: true + singularity_volumes: $defaults + tools: + - class: local + environment: local + +This example runs the workflow on a SLURM cluster, using Singularity to resolve tool dependencies. However, it +can be easily adapted to use Docker or Conda instead. For more details on configuring the ``job_config.yaml`` file, +refer to the `job configuration documentation `__ + +**Note:** before using the example remember to update ``PATH`` and ``PARTITION_NAME`` values to match your system’s configuration. + +Run using the default SQLite database +^^^^^^^^^^^^^^ +:: + + planemo run tutorial.ga tutorial-job.yml \ + --download_outputs \ + --output_directory . \ + --output_json output.json \ + --job_config_file job_config.yaml \ + --biocontainers + +Run using a temporary PostgreSQL database +^^^^^^^^^^^^^^ +:: + + planemo run tutorial.ga tutorial-job.yml \ + --download_outputs \ + --output_directory . \ + --output_json output.json \ + --job_config_file job_config.yaml \ + --biocontainers \ + --database_type postgres_singularity + +Slurm with TPV +~~~~~~~~~~~~~~~~~~ +To make it easier to configure resource used by the different tools we can +use `TPV (Total Perspective Vortex) `_ to +set the resources used by each individual tool. This well require some changes to the +``job_config.yaml``. + +**job_config.yaml** +:: + + runners: + local: + load: galaxy.jobs.runners.local:LocalJobRunner + + drmaa: + load: galaxy.jobs.runners.drmaa:DRMAAJobRunner + drmaa_library_path: PATH/slurm-drmaa-1.1.4/dist/lib/libdrmaa.so + + execution: + default: tpv + environments: + local: + runner: local + tpv: + runner: dynamic + function: map_tool_to_destination + rules_module: tpv.rules + tpv_config_files: + - https://gxy.io/tpv/db.yml + - PATH/destinations.yaml + + tools: + - class: local + environment: local + +**destinations.yaml** +:: + + destinations: + tpvdb_drmaa: + runner: drmaa + params: + native_specification: "-p PARTION_NAME --time=02:00:00 --nodes=1 --ntasks={cores} --ntasks-per-node={cores}" + singularity_enabled: true + singularity_volumes: $defaults + +Like the previous example, this setup submits jobs to a SLURM cluster and uses Singularity to resolve dependencies. The +key difference is the use of **TPV**, which allows you to define resource requirements—such as the number of cores used +by bwa mem—based on settings from the shared configuration a ``https://gxy.io/tpv/db.yml`` + +These defaults can be customized either by providing an entirely new db.yaml file or by overriding specific tool settings +in a separate YAML file. For more details, see the , see `using-the-shared-database `__ section of the TPV documentation. + +**Note:** even if your SLURM scheduler does not use ntasks, you should still set it when a tool is intended to use more +than one core. If not specified, Galaxy will default to using a single core for that tool. + +Troubleshooting +------------------ + +**Temp direcory not shared between nodes** + +Galaxy uses a temporary directory when creating and running jobs. +This directory must be accessible to both the server that creates +the job and the compute node that executes it. If this folder is +not shared, local jobs will succeed, while those submitted to a +separate compute node will fail. To resolve this issue, configure +a shared folder as the temporary directory. + +:: + + TMPDIR=PATH_TO_SHARED_TEMPORARY_FOLDER planemo run ... + +**Locked database** + +While running jobs, Galaxy tracks their status using a database. +The default database is SQLite, which may encounter issues when +handling a high number of concurrent jobs. In such cases, you may see errors like this: + + +:: + + cursor.execute(statement, parameters) + sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) database is locked + [SQL: SELECT kombu_queue.id AS kombu_queue_id, kombu_queue.name AS kombu_queue_name + FROM kombu_queue + WHERE kombu_queue.name = ? + LIMIT ? OFFSET ?] + +The solution is to switch to a more robust database, such as PostgreSQL. + +**Multiple galaxy instances** + +When you run ``planemo run`` a temporary Galaxy instance is created and +in some cases that instance my not be properly shut down. This can cause +the following error: + +:: + + bioblend.ConnectionError: Unexpected HTTP status code: 500: Internal Server Error: make sure that you don't already have a running galaxy instance. + +You will be able to see if instances are still running using the following commands: + +:: + + # Find running galaxy instances + ps aux | grep galaxy + # Find running planemo commands + ps aux | grep planemo diff --git a/docs/running.rst b/docs/running.rst index e130d373a..e20d9c3f3 100644 --- a/docs/running.rst +++ b/docs/running.rst @@ -20,4 +20,5 @@ the ``planemo run`` command, which allows Galaxy tools and workflows to be executed simply via the command line. .. include:: _running_intro.rst -.. include:: _running_external.rst \ No newline at end of file +.. include:: _running_external.rst +.. include:: _running_slurm.rst \ No newline at end of file diff --git a/docs/slurm_cluster_workflows.rst b/docs/slurm_cluster_workflows.rst deleted file mode 100644 index e8d75b4ca..000000000 --- a/docs/slurm_cluster_workflows.rst +++ /dev/null @@ -1,265 +0,0 @@ -Galaxy Workflows on a local cluster -============================================ - -Some users may be unable to upload data to publicly available Galaxy -instances due to legal restrictions. While they might have access to -locally hosted cluster systems, these systems may not allow hosting -web servers or have the necessary personnel to maintain a Galaxy -instance. In such cases, Planemo provides a solution by spinning up -a temporary local Galaxy instance, allowing users to execute -workflows. Jobs can then be run on the same server or submitted to a -workload manager, such as slurm. - -Software requirements ---------------------- -Planemo -~~~~~~~~~~~~~~~~~~ - -If planemo isn't available on the system, it can be easily installed -in a virtual environment. -:: - - python -m venv planemo_venv - . planemo_venv/bin/activate - pip install planemo - -Additional instructions to install planemo can be found at -`install planemo `__. - -DRMAA library -~~~~~~~~~~~~~~~~~~ -To run workflows on a cluster, Galaxy requires access to DRMAA libraries, -which allow communication with the workload manager. -If your system does not include DRMAA libraries, you will need to compile -them manually. For SLURM, the source code and compilation instructions -are available on GitHub:: `slurm-drmaa `__. - -:: - - # Download and extract source code - wget https://github.com/natefoo/slurm-drmaa/releases/download/1.1.4/slurm-drmaa-1.1.4.tar.gz - tar -xvzf slurm-drmaa-1.1.4.tar.gz - cd slurm-drmaa-1.1.4 && mkdir dist - - # Configure build - ./autogen.sh - ./configure --prefix=${PWD}/dist - - # Compile and install - make - make install - - # print path to library - LIBDRMAA=`ls ${PWD}/dist/lib/libdrmaa.so` - echo "Library: ${LIBDRMAA}" - - -Tool dependencies -~~~~~~~~~~~~~~~~~~ -To run a tool/workflow on a server or cluster, the required tools must -be available on the system. If they are not, Galaxy can manage dependencies -using Conda, Docker or Singularity. While Conda is an option, Docker or -Singularity is recommended for its greater reliability. One of the following -environments need to be available on the system: - -- Complete set of used tools installed in the system -- Conda -- Docker -- Singularity - - -Database ------------------- -Galaxy uses a database to track jobs and their statuses, with SQLite as the default -option. However, when running more complex workflows, errors can occur if multiple -jobs are updated simultaneously, leading to database locking and causing the workflow -to terminate prematurely. This issue can be easily avoided by switching to a -PostgreSQL database instead of SQLite. If the user doesn't have access to a PostgreSQL -database, planemo can spin up a temporary PostgreSQL instance using Singularity by adding -a ``--database_type postgres_singularity`` to the run comman. - -Configuration ------------------- -To apply the settings needed for running a workflow/tool you need to configure a job_conf.yaml -file, some of the settings can be applied using the command line, for example: - -- use temporary postgres database: ``--database_type postgres_singularity`` -- use containers for tools: ``--biocontainers`` - -Job configuration -~~~~~~~~~~~~~~~~~~ - -The job configuration file must specify the path to the DRMAA library and define basic -SLURM settings using the `native_specification` tag. For convenience, we will also -configure the Singularity options. - -:: - - runners: - local: - load: galaxy.jobs.runners.local:LocalJobRunner - # modify the number of threads working on local jobs here - # workers: 4 - slurm: - load: galaxy.jobs.runners.slurm:SlurmJobRunner - # modify below to specify a specific drmaa shared library for slurm - drmaa_library_path: /scratch/10171/smeds/run_planemo_using_drmaa/slurm-drmaa-1.1.4/dist/lib/libdrmaa.so - - execution: - default: slurm - environments: - local: - runner: local - singularity_enabled: true - singularity_cmd: singularity - singularity_volumes: $defaults - slurm: - runner: slurm - native_specification: "-p icx,skx --time=02:00:00 --nodes=1" - singularity_enabled: true - singularity_cmd: singularity - singularity_volumes: $defaults - require_container: true - tools: - - class: local - environment: local - - -If your system has a different setup, Galaxy provides `galaxy-job-config-init `__ -, a tool for generating job_config files tailored to various environments and workload managers. -More examples of how to setup the job_configuration file can be found at `job_conf.sample.yaml `__. - -Running ------------------- -Planemo can be run with many different settings, depending on the user's needs. This example -will be running a workflow using slurm and SQLite or PostgreSQL. - -Example workflow -~~~~~~~~~~~~~~~~~~ -Here is the ``job_conf.yaml`` file for the example workflow. It has been modified -to handle two specific tools differently, as they require Conda to run. - -:: - - runners: - local: - load: galaxy.jobs.runners.local:LocalJobRunner - # modify the number of threads working on local jobs here - # workers: 4 - slurm: - load: galaxy.jobs.runners.slurm:SlurmJobRunner - # modify below to specify a specific drmaa shared library for slurm - drmaa_library_path: PATH_TO_LIBRARY/slurm-drmaa-1.1.4/dist/lib/libdrmaa.so - - execution: - default: slurm - environments: - local: - runner: local - singularity_enabled: true - singularity_cmd: singularity - singularity_volumes: $defaults - slurm: - runner: slurm - native_specification: "-p QUEUE_NAME --time=02:00:00 --nodes=1" - singularity_enabled: true - singularity_cmd: singularity - singularity_volumes: $defaults - require_container: true - slurm_conda: - runner: slurm - native_specification: "-p QUEUE_NAME --time=02:00:00 --nodes=1" - conda_enabled: true - require_container: false - tools: - - id: cat1 - environment: slurm_conda - - id: random_lines1 - environment: slurm_conda - - class: local - environment: local - - -Run using the default SQLite database -:: - - git clone https://github.com/usegalaxy-eu/workflow-testing.git - cd workflow-testing/example3 - python3.9 -m venv planemo_venv && source planemo_venv/bin/activate - pip install planemo - # Make sure the temporary folder is shared between servers. - planemo run tutorial.ga tutorial-job.yml \ - --download_outputs \ - --output_directory . \ - --output_json output.json \ - --job_config_file job_config.yaml - -Run using a temporary PostgreSQL database -:: - - git clone https://github.com/usegalaxy-eu/workflow-testing.git - cd workflow-testing/example3 - python3.9 -m venv venv && source venv/bin/activate - pip install planemo - # Make sure that the singulariy command is available - # Make sure the temporary folder is shared between servers. - planemo run tutorial.ga tutorial-job.yml \ - --download_outputs \ - --output_directory . \ - --output_json output.json \ - --job_config_file job_config.yaml \ - --database_type postgres_singularity - - -Troubleshooting ------------------- - -**Temp direcory not shared between nodes** - -Galaxy uses a temporary directory when creating and running jobs. -This directory must be accessible to both the server that creates -the job and the compute node that executes it. If this folder is -not shared, local jobs will succeed, while those submitted to a -separate compute node will fail. To resolve this issue, configure -a shared folder as the temporary directory. - -:: - - TMPDIR=PATH_TO_SHARED_TEMPORARY_FOLDER planemo run ... - -**Locked database** - -While running jobs, Galaxy tracks their status using a database. -The default database is SQLite, which may encounter issues when -handling a high number of concurrent jobs. In such cases, you may see errors like this: - - -:: - - cursor.execute(statement, parameters) - sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) database is locked - [SQL: SELECT kombu_queue.id AS kombu_queue_id, kombu_queue.name AS kombu_queue_name - FROM kombu_queue - WHERE kombu_queue.name = ? - LIMIT ? OFFSET ?] - -The solution is to switch to a more robust database, such as PostgreSQL. - -**Multiple galaxy instances** - -When you run ``planemo run`` a temporary Galaxy instance is created and -in some cases that instance my not be properly shut down. This can cause -the following error: - -:: - - bioblend.ConnectionError: Unexpected HTTP status code: 500: Internal Server Error: make sure that you don't already have a running galaxy instance. - -You will be able to see if instances are still running using the following commands: - -:: - - # Find running galaxy instances - ps aux | grep galaxy - # Find running planemo commands - ps aux | grep planemo