Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleHow to write a support ticket

We are constantly trying to improve our documentation on the PC2 systems. Kindly read this before asking questions via help tickets.

To help us serve you better, when you submit a help ticket, please:

  • Open a new ticket for new issues. Replying to email from the ticketing system will append to the existing ticket. New issues need to have their own, new ticket. Do not reply to a previous email if you are starting a new ticket.

  • Provide a descriptive subject line, succinctly summarizing the problem. Something like "HPC problems" is NOT very useful to us.

  • Include

    • your project and your account used at PC2 (e.g. project: hpc-prf-dfgh, account: dfgh001)

    • the name of the cluster you are experiencing a problem with (e.g. Noctua1, Noctua2, etc).

    • The job-IDs, f there are jobs involved in the issue

    • The full path to the job script you used to submit the job, and for the stdout/stderr error files from the jobs.

  • If you received an error message when running a command (not already in the stderr/stdout files above) please provide the message. The script command (see below) might be helpful.

  • Please do NOT attach the contents of the files above, or include them in the body of the message. Just provide the paths to the files on the system. If you plan to submit the job again with a slightly modified version of the file, please copy it and give us the name that you copied it to.

  • Please, PLEASE do NOT attach screen shots of text. Please get the output into a file (see the script command below to capture output if needed), and give us the path to that file.

  • If you are reporting what seem to be problems with your jobs being stuck in the pending state in the queue, do NOT delete the jobs unless we tell you to do so. Deleting the jobs makes it harder to diagnose the problems.

  • If you are having connection issues, please include the exact command you are running, the host you are trying to connect to, the username you are using (DO NOT INCLUDE PASSWORDS), the approximate time of the failed attempts (as accurately as you can), and if possible the IP address of the machine you are trying to connect from.

  • For follow ups on the same ticket number, we already have a history of the ticket and so you do NOT have to repeat things in every response.

  • If possible, how can we reproduce the error in a systematic manner?

  • Did you attempt to fix/troubleshoot the problem? If you attempted to debug the problem, provide us the steps you already took and the intermediate results.

Expand
titleHow to use script to record actions

Sometimes when diagnosing an issue, we will ask you to show us exactly what commands you issued and what they returned. Or, you need to show us a long complicated error message. An useful tool in these cases is the scriptcommand; once you issue it, it will start a new shell and log all of your input to and all the output from the new shell. This is not that useful for programs that run in a graphical environment, but provides a fairly good log for command line processes.

For example, in the following, we log the session to the file help.script in my home directory:

Code Block

ln0001:~: script help.script
Script started, file is help.script
ln0001:~: date
Tue Oct 21 10:41:07 EDT 2021
ln0001:~:  module list
Currently Loaded Modulefiles:
  1) dept/Glue
ln0001:~:  ncap2
ncap2: Command not found.
ln0001:~: exit
exit
Script done, file is help.script
ln0001:~:
ln0001:~: cat help.script
Script started, file is help.script
ln0001:~: date
Tue Oct 21 10:41:07 EDT 2021
ln0001:~:  module list
Currently Loaded Modulefiles:
  1) dept/Glue
ln0001:~:  ncap2
ncap2: Command not found.
ln0001:~: exit
exit

Script done on Tue Oct 21 10:42:51 2014
ln0001:~:

NOTE: Always remember to exit the shell started by the script command. And, as in the above example, it can be useful to print the contents of the file (e.g. with the cat command) to verify things were properly recorded.

...