[slurm-users] Prolog and job_submit

Chris Samuel chris at csamuel.org
Mon Oct 31 05:32:40 UTC 2022

On 30/10/22 12:27 pm, Davide DelVento wrote:

> But if I understand correctly your Prolog vs TaskProlog distinction,
> the latter would have the environmental variable and run as user,
> whereas the former runs as root and doesn't get the environment,

That's correct. My personal view is that injecting arbitrary input from 
a user (such as these environment variables) would make life hazardous 
from a security point of view for a root privileged process such as a 

> not even from the job_submit script.

That is correct, all the job_submit will do is inject the environment 
variable into the jobs environment, just as if a user had done so.

> The problem with a TaskProlog
> approach is that what I want to do (making a non-accessible file
> available) would work best as root. As a workaround is that I could
> make that just obscure but still user-possible. Not ideal, but better
> than nothing as it is now.
> Alternatively, I could use another way to let the job_submit lua
> script communicate with the Prolog, not sure exactly what (temp
> directory on the shared filesystem, writeable only by root??)

My only other thought is that you might be able to use node features & 
job constraints to communicate this without the user realising.

For instance you could declare the nodes where the software is installed 
to have "Feature=mysoftware" and then your job submit could spot users 
requesting the license and add the constraint "mysoftware" to their job. 
The (root privileged) Prolog can see that via the SLURM_JOB_CONSTRAINTS 
environment variable and so could react to it.

Then when 23.02 comes out you could use the new SLURM_JOB_LICENSES 
environment variable in addition and retire the old way once jobs using 
the old method have completed.

> Thanks for pointing to that commit. I bit too down the road but good to know.

No worries, best of luck!

All the best,
Chris Samuel  :  http://www.csamuel.org/  :  Berkeley, CA, USA

More information about the slurm-users mailing list