Apptainer/en: Difference between revisions

Apptainer/en (view source)

Revision as of 17:24, 29 July 2023

17 bytes removed , 1 year ago

Updating to match new version of source page

FuzzyBot

Bots

38,760

edits

@@ Line 192: / Line 192: @@
 <b>NOTE 1:</b> Don't run daemons manually without using <code>apptainer instance</code> and related commands. Apptainer works properly with other tools such as the Slurm scheduler that run on our clusters. When a job is cancelled, killed, crashes, or is otherwise finished, daemons run using <code>apptainer instance</code> will not hang or result in defunct processes. Additionally by using the <code>apptainer instance</code> command you will be able to control the daemons and programs running in the same container.
-<b>NOTE 2:</b> Running daemons in your job will only run those daemons while your job runs. The scheduler will kill all processes attached to a job when the granted job time expires. If you need to run daemons continuously for longer than a job, submit a ticket asking to discuss such with staff persons. Such may require creating a cloud virtual machine to achieve such.
+<b>NOTE 2:</b> Daemons can only run in your job while your job is running. Should the scheduler kill your job, all daemons running in that job will also be killed. Should you need to run daemons longer than the job they were started in, you may need to also have a virtual machine running in the cloud. If so please contact [[technical support]].
 ==Running MPI programs==
@@ Line 210: / Line 210: @@
 ==Bind mounts==
-When Apptainer is used with the <code>-C</code> or <code>-c</code> options, one will notice that they cannot access their disk space when inside the container. The remedy for this is to explicitly bind mount the disk space they wish to access. For example, suppose a user was using <code>-C</code> like this in an sbatch job to use apptainer:
+When Apptainer is used with the <code>-C</code> or <code>-c</code> options, one will notice that they cannot access their disk space when inside the container. The remedy for this is to explicitly bind mount the disk space they wish to access. For example, suppose a user was using <code>-C</code> like this in an <code>sbatch</code> job to use Apptainer:
   apptainer run -C -W $SLURM_TMPDIR a-container.sif wc -l ./my_data_file.txt
-where <code>./my_data_file.txt</code> is a file in the current directory on the host, i.e., the file is not stored in the container at all. Because of the <code>-C</code> option, this file will not be accessible to the <code>wc</code> program inside the container --and so an access error will result. The fix is to bind mount the current directory, e.g.,
+where <code>./my_data_file.txt</code> is a file in the current directory on the host, i.e., the file is not stored in the container at all. Because of the <code>-C</code> option, this file will not be accessible to the <code>wc</code> program inside the container and an access error will result. The fix is to bind mount the current directory, e.g.,
   apptainer run -C -B . -W $SLURM_TMPDIR a-container.sif wc -l ./my_data_file.txt
@@ Line 220: / Line 220: @@
 where <code>-B .</code> will bind mount the current directory, <code>.</code>.
-While one can have multiple bind mounts specified, often it is easier to specify the top directories of the filesystems one wishes to access. For example, on our clusters one might want to use:
+While one can have multiple bind mounts specified, it is often easier to specify the top directories of the filesystems one wishes to access. For example, on our clusters one might want to use
   apptainer run -C -B /home -B /project -B /scratch -W $SLURM_TMPDIR a-container.sif wc -l ./my_data_file.txt
@@ Line 231: / Line 231: @@
 Doing this is especially useful when:
 * you need to access others' files on your research time in other locations, and/or,
-* you need to access files/directories some of which are symlinks to different locations that would/might otherwise be broken if you did not mount the entire filesystem.
+* you need to access files/directories some of which are <code>symlinks</code> to different locations that would/might otherwise be broken if you did not mount the entire filesystem.
-If using these bind mounts do not work on the cluster you are using, then run this script to obtain the bind mount options you need to pass to Apptainer for /home, /project, and /scratch on that cluster:
+If using these bind mounts does not work on the cluster you are using, run this next script to obtain the bind mount options you need to pass to Apptainer for /home, /project, and /scratch on that cluster
   /home/preney/public/apptainer-scripts/get-apptainer-options.sh
@@ Line 243: / Line 243: @@
 i.e., <code>-B ./my_data_file.txt:/special/input.dat</code> bind mount maps the file <code>./my_data_file.txt</code> to be the file <code>/special/input.dat</code> inside the container and the <code>wc</code> command now processes that file. This feature can be useful when programs/scripts inside the container have hard-coded paths to files and directories that must be located in certain locations.
-Finally, <b>don't mount our CVMFS paths</b> inside your containers as this is fraught with perils and defeats many reasons to use a container. The programs needed to be run inside a container need to be completely inside the container --don't introduce even more programs inside the container that don't need to be inside the container.
+Finally, <b>don't mount our CVMFS paths</b> inside your containers as this is fraught with perils and defeats many reasons to use a container. The programs that have to run inside a container need to be completely inside the container. Don't introduce even more programs inside the container if they don't need to be there.
 ==Persistent overlays==