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

[Alan Orth]

Regarding setting limits for users on the head node. We had this for years:

# CPU time in minutes
*       -   cpu         30
root    -   cpu         unlimited

But we eventually found that this was even causing long-running jobs like
rsync/scp to fail when users were copying data to the cluster. For a while
I blamed our network people, but then I did some tests and found that it
was the limits that were responsible. I have removed this and other limits
for now but I ruthlessly kill heavy processes that my users run on there. I
will look into using cgroups on the head node.

Cheers,

On Sat, Apr 24, 2021 at 11:05 AM Ole Holm Nielsen <
Ole.H.Nielsen at fysik.dtu.dk> wrote:

> On 24-04-2021 04:37, 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 ?
>
> We restrict user limits in /etc/security/limits.conf so users can't run
> very long or very big tasks on the login nodes:
>
> # Normal user limits
> *               hard    cpu             20
> *               hard    rss             50000000
> *               hard    data            50000000
> *               soft    stack           40000000
> *               hard    stack           50000000
> *               hard    nproc           250
>
> /Ole
>
>

-- 
Alan Orth
alan.orth at gmail.com
https://picturingjordan.com
https://englishbulgaria.net
https://mjanja.ch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20210519/f618d446/attachment.htm>