Apptainer: Difference between revisions

| <code>-C</code> || Isolates the running container from all file systems as well as the parent PID, IPC, and environment. Using this option will require [[#Bind_Mounts|using bind mounts]] if access to filesystems outside of the container is needed.

| <code>-c</code> || Isolates the running container from most file systems only using a minimal <code>/dev</code>, an empty <code>/tmp</code> directory, and an empty <code>/home</code> directory. Using this option will require [[#Bind_Mounts|using bind mounts]] if access to filesystems outside of the container is needed.

Another important option is the <code>-W</code> or <code>--workdir</code> option. On Alliance clusters and on most Linux systems, <code>/tmp</code> and similar filesystems use RAM, not disk space. Since jobs typically run on our clusters with limited RAM amounts, this can result in jobs getting killed because they consume too much RAM relative to what was requested for the job. A suitable workaround for this is to tell Apptainer to use a real disk location for its working directory ("workdir"). This is done by passing the <code>-W</code> option followed by a path to a disk location where Apptainer can read/write temporary files, etc. For example, suppose one wanted to run a command called <code>myprogram</code> in a using an Apptainer container image called <code>myimage.sif</code> with its "workdir" set to <code>/path/to/a/workdir</code> in the filesystem:

* The workdir can be removed if there are no live containers using it.

* When using Apptainer in an <code>salloc</code>, in an <code>sbatch</code> job, or when using [JupyterHub] on our clusters, use <code>${SLURM_TMPDIR}</code> for the "workdir" location, e.g., <code>-W ${SLURM_TMPDIR}</code>.

* When using bind mounts, see the [[#Bind_Mounts|section on bind mounts]] below since not all Alliance clusters are the same concerning the exact bind mounts needed to access <code>/home</code>, <code>/project</code>, and <code>/scratch</code>.