on.me/) secure email.
On Saturday, February 24th, 2024 at 9:44 PM, urbanjost via slurm-users
wrote:
> There are scontrol subcommands uhold/hold/release/requeuehold that are
> ignored when describing how to place a job on hold in FAQ 21; and it is never
> explained why the method describ
There are scontrol subcommands uhold/hold/release/requeuehold that are ignored
when describing how to place a job on hold in FAQ 21; and it is never explained
why the method described therein is the best method, it just states it is. Does
anyone know why the FAQ method is better than using the s
I do not see how to use the suffix for the --Format option of the
squeue(1) command. The description does not indicate how to tell the
end of the size and period components and the beginning of the suffix,
but assuming the suffix must being with something other than a period
or numeric character I
If I use the sbatch(1) option --export=NONE or wipe the environment with "env
-i /usr/bin/sbatch ..." or use --export=NIL then the environment is not
properly constructed and I see
the message in the /var/log/*slurm* files:
[2024-02-03T11:50:33.052] _get_user_env: get env for user jsu here
[2024
log files use many strings to identify job, including not having a jobID in the
message
NUMBER=$SLURM_JOBID
egrep "\.\<$NUMBER\>\] |\<$NUMBER\>\.batch|jobid
\<$NUMBER\>|JObId=\<$NUMBER\>|job id \<$NUMBER\>|job\.\<$NUMBER\>|job
\<$NUMBER\>|jobid \[\<$NUMBER\>\]|task_p_slurmd_batch_request: \<$NUM
RE: Placing the full pathname of the job stdout in an environment variable
Would others find it useful if new variables were added that contained the full
pathnames of the standard input, error and input files of batch jobs?
## SYNOPSIS
Proposed new environment variables SLURM_STDOUT,SLURM_STDE