Reports whether Slurm started this R process. A script that submits itself calls this, so it submits from the login session and never from inside the job.
Details
Without the test, the submitting branch runs inside the job as well, and the job submits itself again:
if (!inside_slurm_job()) {
slurm_submit(slurm_write(jobs, dir))
quit(save = "no")
}
# Below here runs inside the job.What it reads
It reads SLURM_JOB_ID first. It falls back to SLURM_JOBID, which the
sbatch manual page keeps for backward compatibility. Measured on Slurm
25.11.2: a login shell carries no SLURM_ variable at all, and a one-task
job carries 33 of them.
Any non-empty value counts as inside a job. A digit check would be wrong,
because a heterogeneous job carries an id such as 17+1. A false negative
there makes the payload submit itself, which costs more than a false
positive from a hand-set variable.
plnr::is_run_directly() does not answer this question. It tests the call
depth, not the environment. Measured on this machine, it returns TRUE on
the login node and inside a Slurm job.
See also
vignette("batchit"), section "Slurm: write a chain of jobs".
Other slurm:
slurm_it(),
slurm_status(),
slurm_submit(),
slurm_write()
