Support

When your work stops, the fastest route forward is a clear diagnosis and a support request with the right evidence. This page helps you solve common problems, choose the right support path, and give the Deceema team what they need to act quickly.

• Account and Access

  Login problems, missing projects, incorrect QoS options, or account changes.

  Review access guidance

• Jobs and Compute

  Jobs that are pending, fail unexpectedly, or produce incorrect output.

  Open the jobs guide

• Storage and Data

  Missing files, permissions, capacity, transfer, or performance concerns.

  Review storage guidance

• Portal and Applications

  Interactive sessions, hosted applications, browser access, VMs, or containers.

  Open the portal guide

Start with a Two-Minute Check

Before opening a support request:

1. Check Service Status for a known incident or planned maintenance.
2. Read the guide for the affected service and confirm that the command, project code, QoS, path, or URL is correct.
3. Retry the smallest safe step that reproduces the problem.
4. Record the exact error, time, command, host, and relevant job or project ID.
5. Decide whether the issue affects only you, a project team, or many users.

This short check often reveals a configuration issue immediately. If it does not, it gives support a strong starting point.

Never send secrets

Do not include passwords, multi-factor authentication codes, private keys, access tokens, credentials, or unredacted sensitive data in a support request, screenshot, or log file.

How Urgent Is the Issue?

Priority	Examples	What to do
Urgent	Suspected account compromise, exposed credentials, unexpected access, or a potential data-security incident.	Stop the affected activity and contact the approved Deceema support channel immediately. Do not share secrets or destroy diagnostic evidence.
High impact	A service appears unavailable, many users are affected, or time-sensitive project work cannot continue.	Check Service Status, then report the scope, first observed time, and business or research impact.
Standard	A single job fails, a file permission is wrong, an application behaves unexpectedly, or account details need correction.	Gather the diagnostics below and submit a normal support request.
Guidance	You need help choosing resources, writing a job script, managing data, or using an application.	Start with the relevant documentation and explain the outcome you want to achieve if you still need help.

Priority should describe the impact, not just the inconvenience. A precise impact statement helps the team triage the request correctly.

Build a Support Request That Gets Results

A strong request answers four questions:

1. What were you trying to do?
2. What did you expect to happen?
3. What actually happened?
4. What evidence can reproduce or explain it?

Copy this template into your organization's approved Deceema support channel:

Support request template

Subject: [Area] Short description of the problem

Name:
Deceema username:
Project code:
QoS, if relevant:
Affected service or application:
Hostname, if known:
Job ID, if relevant:

First observed (date, time, and time zone):
Impact: [one user / project team / multiple users]

What I was trying to do:

What I expected:

What happened instead:

Exact command or steps to reproduce:

Exact error message:

What I have already tried:

Recent changes that may be relevant:

Attachments: [sanitized logs, job script, or screenshot]

One issue per request

Keep unrelated problems in separate requests. This makes ownership, investigation, and resolution clearer for everyone.

Capture Useful Diagnostics

Run only commands you understand and include only output relevant to the problem. Remove secrets and sensitive data before sharing it.

General environment

These commands establish who, where, and when:

$ date
$ hostname
$ whoami

For account issues, explain which project or QoS your approval information lists, what you expected, and what access is actually unavailable.

Slurm jobs

Replace JOB_ID with the affected Slurm job ID:

$ squeue --jobs=JOB_ID
$ scontrol show job JOB_ID

If job accounting is available, this command provides a concise history:

$ sacct --jobs=JOB_ID --format=JobID,JobName,State,ExitCode,Elapsed,MaxRSS

Also attach the job script and the relevant standard output and error files. Remove credentials, tokens, private data, and unrelated output first.

Files and storage

Record the exact affected path and capture its permissions:

$ pwd
$ ls -ld AFFECTED_PATH
$ df -h AFFECTED_PATH

Do not alter permissions or delete files merely to test a theory. Report the project code, path, expected access, and whether teammates see the same issue.

Portal and browser applications

Include:

• The application name and page or action that failed.
• The date, time, and time zone of the failure.
• Browser name and version.
• Whether the problem occurs in a new private browsing session.
• A sanitized screenshot of the visible error, if useful.

Never capture passwords, tokens, personal data, or confidential project content in a screenshot.

Troubleshoot Common Scenarios

My Slurm job is pending

Capture the job ID and squeue --jobs=JOB_ID output. Verify that the --account and --qos values match your approved project details, and include the requested time, tasks, memory, and GPU resources in your support request.

A pending job is not necessarily broken—it may be waiting for resources or another scheduling condition. The reported job state and reason are more useful than the wait time alone.

My Slurm job failed

Include the job ID, job script, exit state, and the smallest relevant section of standard output and error. Explain whether the job has worked before and what changed since the last successful run.

I cannot sign in

Record the connection method, destination, exact error, and time of the attempt. Confirm that your account activation is complete. Never send your password, authentication code, or private key.

I cannot access a file or directory

Include the exact path, project code, expected access, and sanitized output from ls -ld AFFECTED_PATH. Ask a teammate whether the issue affects the whole project, but do not change permissions without understanding the impact.

A portal application will not start

Check Service Status, then capture the application name, launch time, visible error, browser version, and requested resources. State whether a retry produces the same result.

After You Submit

• Keep the job script, logs, and affected files available while the issue is investigated.
• Reply in the same support thread so evidence and decisions remain together.
• Report new symptoms, workarounds, or impact changes as they occur.
• Test the proposed resolution with the smallest representative workload.
• Confirm when the issue is resolved and briefly describe what worked.

Still Not Sure Where to Begin?

Start with the outcome you want, not a diagnosis you are uncertain about. A short message such as “I am trying to submit my first GPU job, but the project listed in my approval information is not available to my account” gives support a clear direction and useful context.

Review Getting Started Check Service Status