Singularity - Revision history

GiulioFontana: /* shell */

2025-11-25T17:53:29Z

shell

← Older revision		Revision as of 17:53, 25 November 2025
Line 438:		Line 438:
	</pre>		</pre>

	For example, from within an interactive SLURM session, we can start a container from a previously built sandbox image and open a terminal in it to install a desired Ubuntu package:		For example, from within an interactive SLURM session, we can start a container from a previously built sandbox image and open a terminal in it to install a desired Ubuntu package. The following command starts the container in interactive mode:

	<pre style="color: lightgrey; background: black;">		<pre style="color: lightgrey; background: black;">
	~~# Starting the container in interactive mode.~~
	~~# Note: Remember the appropriate flags to make the container filesystem writable and connect to the terminal as~~
	~~# the container's root user.~~
	singularity shell --fakeroot --writable ubuntu/		singularity shell --fakeroot --writable ubuntu/
			</pre>

			Note that we used the appropriate flags to make the container filesystem writable and to connect to the terminal as the container's root user.

			Once the container is running and we have access to the shell within it, it is possible to run (as root) commands: for instance, to update 'apt' package list and install a package of interest (e.g., htop) the commands to run would be

	~~# From within the container, update 'apt' package list and install a package of interest (e.g., htop)~~		<pre style="color: lightgrey; background: black;">
	apt-get update		apt-get update
	apt-get install htop		apt-get install htop

PierluigiReali: /* Example */

2025-11-25T16:50:41Z

Example

← Older revision		Revision as of 16:50, 25 November 2025
Line 522:		Line 522:
	=== Example ===		=== Example ===

	The following example shows how a user can run a container as an instance (i.e., in ''detached mode'') and later attach to it to perform operations supported by services running in the same container.		The following example shows how a user can run a container as an instance (i.e., in ''detached mode'') and later ''attach'' to its console to perform operations supported by services running in the same container.

	The following command builds the Ollama container image (it should be run only once):		The following command builds the Ollama container image (it should be run only once):

PierluigiReali: /* Caveats */

2025-11-25T16:49:38Z

Caveats

← Older revision		Revision as of 16:49, 25 November 2025
Line 518:		Line 518:
	For these reasons, the [[Singularity#Exec\|<code>exec</code> sub-command]] must always be preferred to <code>instance run</code> except when unsuitable.		For these reasons, the [[Singularity#Exec\|<code>exec</code> sub-command]] must always be preferred to <code>instance run</code> except when unsuitable.

	'''Advice:''' Even you really need the <code>instance run</code> modality, first try it out in an interactive SLURM session requesting only a few CPU cores and little memory to get familiar with the process before launching your actual instances as non-interactive SLURM jobs.		'''Advice:''' Even if you really need the <code>instance run</code> modality, first try it out in an interactive SLURM session requesting only a few CPU cores and little memory to get familiar with the process before launching your actual instances as non-interactive SLURM jobs.

	=== Example ===		=== Example ===

PierluigiReali: /* Terminating an instance */

2025-11-25T16:48:43Z

Terminating an instance

← Older revision		Revision as of 16:48, 25 November 2025
Line 507:		Line 507:

	<pre style="color: lightgrey; background: black;">		<pre style="color: lightgrey; background: black;">
	scancel <~~slurm_job_number~~>		scancel <slurm_job_ID>
	</pre>		</pre>

PierluigiReali: /* Terminating and instance */

2025-11-25T16:48:00Z

Terminating and instance

← Older revision		Revision as of 16:48, 25 November 2025
Line 494:		Line 494:
	</pre>		</pre>

	=== Terminating ~~and~~ instance ===		=== Terminating an instance ===

	When the user doesn't need a running instance anymore, they should close the SSH session open on the Mufasa host and simply stop the instance by terminating the associated SLURM job from the Mufasa ''login'' subsystem with the following operations:		When the user doesn't need a running instance anymore, they should close the SSH session open on the Mufasa host and simply stop the instance by terminating the associated SLURM job from the Mufasa ''login'' subsystem with the following operations:

PierluigiReali: /* Interacting with running instances */

2025-11-25T16:47:08Z

Interacting with running instances

← Older revision		Revision as of 16:47, 25 November 2025
Line 468:		Line 468:
	=== Interacting with running instances ===		=== Interacting with running instances ===

	While an instance is running under a SLURM job launched from the Mufasa [[System#Login server\|login server]] subsystem, it is possible for the user to open another SSH session and [System# Direct access to Mufasa (for users with running SLURM jobs)\|log in directly to the Mufasa host]]. From the shell to the host, after executing		While an instance is running under a SLURM job launched from the Mufasa [[System#Login server\|login server]] subsystem, it is possible for the user to open another SSH session and [[System# Direct access to Mufasa (for users with running SLURM jobs)\|log in directly to the Mufasa host]]. From the shell to the host, after executing

	<pre style="color: lightgrey; background: black;">		<pre style="color: lightgrey; background: black;">

PierluigiReali: /* Example script for model training */

2025-11-25T16:42:05Z

Example script for model training

← Older revision		Revision as of 16:42, 25 November 2025
Line 333:		Line 333:
	'''<nowiki>#</nowiki>SBATCH --ntasks=1'''		'''<nowiki>#</nowiki>SBATCH --ntasks=1'''

	'''<nowiki>#</nowiki>SBATCH --cpus-per-task=<<number of CPU cores your container needs>'''		'''<nowiki>#</nowiki>SBATCH --cpus-per-task=<number of CPU cores your container needs>'''
	<nowiki>#</nowiki>---4 cores are usually sufficient for GPU-intensive tasks: ask for more only if actually needed		<nowiki>#</nowiki>---4 cores are usually sufficient for GPU-intensive tasks: ask for more only if actually needed

PierluigiReali: /* exec */

2025-11-25T16:37:46Z

exec

← Older revision		Revision as of 16:37, 25 November 2025
Line 290:		Line 290:
	The <code>singularity exec</code> command executes a specific command within a container without opening a shell (i.e., non-interactively).		The <code>singularity exec</code> command executes a specific command within a container without opening a shell (i.e., non-interactively).

	The command to be executed is specified directly via the command line, i.e. it is a part of the <code>singularity exec</code> command~~. It is run after the commands in the <code>%runscript</code> section of the ''definition file''~~.		The command to be executed is specified directly via the command line, i.e. it is a part of the <code>singularity exec</code> command.

	The general syntax to use the <code>exec</code> sub-command is the following:		The general syntax to use the <code>exec</code> sub-command is the following:

PierluigiReali: /* Useful options */

2025-11-25T16:33:35Z

Useful options

← Older revision		Revision as of 16:33, 25 November 2025
Line 282:		Line 282:

	; <code>--writable</code>		; <code>--writable</code>
	:: This flag is needed only if we need to modify the content of paths owned by the container's <code>root</code> user (e.g., to install new applications interactively or modify system files), in which case it is usually combined with the <code>--fakeroot</code> option. The <code>--writable</code> option is ''not'' needed if we just need to ''mount'' a local path on a privileged directory within the container, as explained earlier. Moreover, it generally makes sense to use this flag only when running containers created from sandbox images. Limitation: <code>--writable</code> and <code>--nv</code> options cannot be applied simultaneously (the container starts properly, but GPU resources cannot be accessed).		:: This flag is needed only if we need to modify the content of paths owned by the container's <code>root</code> user (e.g., to install new applications interactively or modify system files), in which case it is usually combined with the <code>--fakeroot</code> option. The <code>--writable</code> option is ''not'' needed if we just need to ''mount'' a local path on a privileged directory within the container, as explained earlier. Moreover, it generally makes sense to use this flag only when running containers created from sandbox images. '''Limitation:''' <code>--writable</code> and <code>--nv</code> options cannot be applied simultaneously (the container starts properly, but GPU resources cannot be accessed).

	The following sections provide examples of use of these options.		The following sections provide examples of use of these options.

PierluigiReali: /* Useful options */

2025-11-25T16:30:17Z

Useful options

← Older revision		Revision as of 16:30, 25 November 2025
Line 149:		Line 149:
	; <code>--sandbox</code>		; <code>--sandbox</code>
	:: enables the filesystem image to be built as a directory that the user can modify, instead of a single SIF file		:: enables the filesystem image to be built as a directory that the user can modify, instead of a single SIF file

	~~; <code>--writable</code>~~
	~~:: makes the filesystem image writable~~

	; <code>--fakeroot</code>		; <code>--fakeroot</code>
Line 159:		Line 156:
	:: enables the image to make use of system GPUs		:: enables the image to make use of system GPUs

	The following sections provide examples of use of these options.		The following sections provide examples of the use of these options.

	== Using SLURM to build Singularity images ==		== Using SLURM to build Singularity images ==