launch.sh Reference¶

This page lists the options launch.sh accepts, the resources it provides by default, and how the resource values passed to it are applied. Work that continues after a terminal session ends is covered in Job Modes, and how long a container may run in The Runtime Limit.

Location and Invocation¶

launch.sh is on the path once a connection to the login node is established. Its absolute path is /opt/launch-sh/bin/launch.sh. Containers run unprivileged under the member's own UID, and no flag grants root or sudo (Root Access and System Packages).

Wrapper Scripts¶

Most work goes through a wrapper. launch-scipy-ml.sh starts the GPU-capable image and launch-datascience.sh starts the CPU image. The images are described in Standard Images, Tags, and Pinning. Each wrapper sets environment variables and then hands off to launch.sh, so every launch.sh flag behaves identically through a wrapper.

Every flag also has an environment-variable equivalent, which is the mechanism the wrappers use. The equivalents are covered in Configuring Without Flags.

Non-Interactive Submission¶

A job submitted in one line from a personal machine names the launcher by its absolute path, because ssh runs a non-login shell in which the launcher is not necessarily on the path.

ssh <user>@dsmlp-login.ucsd.edu /opt/launch-sh/bin/launch.sh -c 8 -m 16 -g 1 \
    -i <image> -f ${HOME}/myproject/run-commands.sh

The VS Code ProxyCommand described in Remote Editor Setup uses the same form.

Defaults and Resource Tiers¶

Default Resources¶

Bare launch.sh and the wrappers start containers with different defaults.

Calling launch.sh directly instead of a wrapper halves the CPU and leaves one eighth of the memory. The usual symptom is a process that dies without an error that explains the cause.

A browser session starts at 2 CPU / 4 GB. That figure is a course's spawn configuration, not a command-line default, and is described in The Browser Session. The three sets of figures describe three different things.

Resource Tiers¶

Limits apply at three tiers. Confusing the tiers is the usual cause of a job that does not schedule.

-m 64 is not a valid request for a single container, although 64 GB is the namespace total. The namespace allowance may be spent across several containers, not in one. Requests for the third tier are made as described in Administrative Requests.

An older article or course README that describes 8 CPU / 64 GB / 1 GPU or 8 CPU / 16 GB / 1 GPU as the platform maximum is describing a default. The 8 CPU / 16 GB / 1 GPU figure is out of date.

Resource Requests and Limits¶

The value passed to -c or -m is the limit, the most the container may use. launch.sh sets the Kubernetes request, the amount the scheduler reserves and the only amount guaranteed, to half the limit. -m 32 reserves 16 GB and permits 32 GB. The second 16 GB is available only if the node the pod runs on has it spare. The same halving applies to CPU.

The halving causes many OOMKilled (out-of-memory) reports. It also explains a job that succeeds on one run and fails on a later run, on a busier node, with no change to its code. Size a job for the guarantee, not the limit: to guarantee a model 16 GB, launch it with -m 32.

GPUs are not halved. A GPU is assigned to one container exclusively, so its request and limit are the same number.

Resource and GPU Selection Flags¶

GPU Class¶

-l gpu-class=<class> requests a GPU size band, and is the way to request a GPU. GPU Classes lists the classes.

Every GPU class is managed by the reservation system, which admits only pods that carry the gpu-class label. A GPU request that omits the label waits in Pending with no event from the reservation system (Missing or Misspelled Class Label).

Workspace and GPU Charges¶

-W <workspace> also sets the pod's dsmlp/course label, which decides which workspace's Service Unit budget a GPU session is charged to, and which bookings it can claim. A GPU launch without -W is charged to ORG_ON_DEMAND, the default workspace, and never claims a course booking. See Claiming a Booking and The Default Workspace.

Team Selection¶

launch-scipy-ml.sh -W DSC180A_FA25_A00 -G list       # find the team ID
launch-scipy-ml.sh -W DSC180A_FA25_A00 -G <teamid>   # then launch with it

-G list is the only way to discover a team ID. Team directory names often contain brackets, which must be quoted in a cd command.

See also: Belonging to Several Workspaces

Image, Workspace, and Placement Flags¶

Image Pull Policy¶

For an image under development, as described in Building & Publishing a Custom Image, pass -i <image> -P Always. Without -P Always, a node already holding that tag keeps using its copy.

Mounts and Package Cache¶

-x is used only at the request of ITS. Describe the data to ITS before using -M or -F.

Node Selection¶

-n takes a bare number: -n 30, not -n n30. The leading n shown on The Status Page is not part of the value. A pod whose named node is full waits for that node and does not take an equivalent GPU elsewhere. To choose a GPU size, use -l gpu-class=.

The launch output names the node the pod was assigned to, in a line such as INFO pod assigned to node: its-dsmlp-n04.ucsd.edu. Include that line in a problem report.

Pod Names¶

-N gives the pod a name by which it can be deleted later. Give a name to any pod left running unattended.

Job Execution Flags¶

Job Modes describes when to use each of -b, -B, and -f. -d prints the specification the cluster would have received and consumes nothing. Its output shows what a set of flags actually requests.

Option Separator¶

-- separates the launcher's options from the command's own. Everything after it is passed into the container untouched.

launch-scipy-ml.sh -g 1 -B -- python train.py --epochs 50 --lr 0.01

Without the separator, launch.sh reads --epochs as one of its own options and fails with a message about a launcher flag, not about the program being run.

Help Output and Undocumented Options¶

The -h summary is generated from comments in the launcher's source and does not list exactly the same flags as this page. It includes options that are not documented on this page: some are legacy, and some interact with scheduling. Consult ITS before using an undocumented option.

Report a problem with this page