[slurm-users] [External] What is an easy way to prevent users run programs on the master/login node.

[Prentice Bisbal]

I'm not sure. I just installed Arbiter myself only a few weeks ago, and 
I'm still learning it. The systems it's installed on haven't gone live 
yet, so I haven't had many "learning opportunities" yet. Arbiter is 
using cgroups, so I would imagine that depends on whether cgroups 
distinguishes between the two or not. But I'm not a cgroups expert, 
either. ;(

Prentice

On 6/11/21 8:01 AM, Stefan Staeglich wrote:

> Hi Prentice,
>
> thanks for the hint. I'm evaluating this too.
>
> Seems that arbiter doesn't distinguish between RAM that's used really and RAM
> that's sused as cache only. Or is my impression wrong?
>
> Best,
> Stefan
>
> Am Dienstag, 27. April 2021, 17:35:35 CEST schrieb Prentice Bisbal:
>> I think someone asked this same exact question a few weeks ago. The best
>> solution I know of is to use Arbiter, which was created exactly for this
>> situation. It uses cgroups to limit resource usage, but it adjusts those
>> limits based on login node utilization and each users behavior ("bad"
>> users get their resources limited more severely when they do "bad" things.
>>
>> I will be deploying it myself very soon.
>>
>> https://dylngg.github.io/resources/arbiterTechPaper.pdf
>> <https://dylngg.github.io/resources/arbiterTechPaper.pdf>
>>
>> Prentice
>>
>> On 4/23/21 10:37 PM, Cristóbal Navarro wrote:
>>> Hi Community,
>>> I have a set of users still not so familiar with slurm, and yesterday
>>> they bypassed srun/sbatch and just ran their CPU program directly on
>>> the head/login node thinking it would still run on the compute node. I
>>> am aware that I will need to teach them some basic usage, but in the
>>> meanwhile, how have you solved this type of user-behavior problem? Is
>>> there a preffered way to restrict the master/login resources, or
>>> actions,  to the regular users ?
>>>
>>> many thanks in advance
>