laptop → clustermulti-service stacks under the schedulerRelease status: v0.1.0
Navigation
Diagnostics

Find a failure by symptom

Choose the symptom you see. Each section shows a short reader code and the stable identifier to use in logs and issue reports.

Container runtime is unavailable

Code: PREREQ-APPTAINER Stable identifier: BSSW-PREREQ-APPTAINER

Signal

command -v apptainer fails, apptainer --version fails, or the runtime is absent on compute nodes.

Likely causes

The runtime module is not loaded, login and compute environments differ, or the center supports another rootless runtime.

Recovery steps

  1. Find the center-documented runtime module or path.
  2. Verify it inside a compute allocation.
  3. Record the runtime version and rerun the prerequisite check.

Warning: Do not install a privileged daemon or bypass center policy.

Verify the recovery

Both command -v apptainer and apptainer --version succeed in the job environment.

Escalate

Ask center support which rootless runtime is approved. This release does not claim another runtime is validated.

Coordinator did not become ready

Code: READINESS-TIMEOUT Stable identifier: BSSW-READINESS-TIMEOUT

Signal

The semantic health check expires. The launcher exits nonzero and no worker-start event occurs.

Likely causes

The coordinator failed, the image is wrong, loopback communication is blocked, job-scoped storage is unwritable, or requested resources are insufficient.

Recovery steps

  1. Inspect the coordinator log and image digest.
  2. Check loopback communication and job-scoped write permissions.
  3. Correct one cause, remove invalid success artifacts, and resubmit within the documented timeout bounds.

Warning: Do not replace semantic health with a fixed sleep or an unbounded loop.

Verify the recovery

Confirm the failed run has this diagnostic code, a nonzero result, cleanup evidence, and no worker-start event. A repaired run must pass readiness before workers.

Escalate

Report sanitized coordinator and readiness logs through support.

Job-scoped storage check failed

Code: STORAGE-UNAVAILABLE Stable identifier: BSSW-STORAGE-UNAVAILABLE

Signal

The selected scratch root is missing or unwritable, quota is insufficient, or the container bind is denied.

Likely causes

The path is not allocated to the job, quota is exhausted, permissions are wrong, or runtime bind policy rejects it.

Recovery steps

  1. Select the center-approved job-scoped path.
  2. Verify ownership and free quota.
  3. Create a private directory for the submitted job.
  4. Test the bind with a non-sensitive file.

Warning: Never fall back silently to shared persistent storage or a world-writable path.

Verify the recovery

The job can create, read, and remove a private test file through the same container bind.

Escalate

Ask center support to confirm the approved scratch and bind policy.

Scheduler prerequisite is unavailable

Code: PREREQ-SLURM Stable identifier: BSSW-PREREQ-SLURM

Signal

sbatch is unavailable, submission authorization is unknown, or a minimal submission is rejected before the job starts.

Likely causes

The scheduler client is not loaded, the account or partition is unauthorized, or the center requires a site-specific submission option.

Recovery steps

  1. Read the center user guide.
  2. Load only the documented scheduler client environment.
  3. Select an authorized account and partition.
  4. Rerun command -v sbatch and the center’s non-submitting account check.

Warning: Do not guess account names.

Verify the recovery

The scheduler command is available and the center confirms an authorized submission target.

Escalate

Contact center support when authorization remains unclear.

If execution is blocked, you can still use the conceptual modules and local adaptation guidance. If no symptom matches, report a missing diagnostic with sanitized reproduction details.