<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Near term, could you make sure their groups are covered in
/etc/security/limits.conf ?</p>
<p>Something like</p>
<p> @users soft cpu 5 # 5 min of cpu time</p>
<p> @users hard cpu 10 # 5 min of cpu time</p>
<p>?</p>
<p>Way ... way back when I helped others do this stuff, I set up
isolated login VMs. Everyone got their own. I could limit them
to 1 core, 4GB ram, and they had queue access (this was in the PBS
days). I lit up like 20 of these small VMs per "login node", each
with their own IP. The VMs could idle fairly nicely. We could
rate limit their (virtual) networks using tc, and throttle their
disk IO. <br>
</p>
<p>Haven't done that in a while. These days, you might look at
login containers for the same thing. Just set up limits on the
memory/network /cpu for those and off to the races you go (SMOP :D
)<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/26/21 9:56 AM, Michael Di Domenico
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABOsP2P=cB1LD_DMV0jyXmygse=cenm96Ze6PQzrfG1AusT9Sw@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">does anyone have a recipe for limiting the damage people can do on
login nodes on rhel7. i want to limit the allocatable cpu/mem per
user to some low value. that way if someone kicks off a program but
forgets to 'srun' it first, they get bound to a single core and don't
bump anyone else.
i've been poking around the net, but i can't find a solution, i don't
understand what's being recommended, and/or i'm implementing the
suggestions wrong. i haven't been able to get them working. the most
succinct answer i found is that per user cgroup controls have been
implemented in systemd v239/240, but since rhel7 is still on v219
that's not going to help. i also found some wonkiness that runs a
program after a user logs in and hacks at the cgroup files directly,
but i couldn't get that to work.
supposedly you can override the user-{UID}.slice unit file and jam in
the cgroup restrictions, but I have hundreds of users clearly that's
not maintainable
i'm sure others have already been down this road. any suggestions?
_______________________________________________
Beowulf mailing list, <a class="moz-txt-link-abbreviated" href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit <a class="moz-txt-link-freetext" href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Joe Landman
e: <a class="moz-txt-link-abbreviated" href="mailto:joe.landman@gmail.com">joe.landman@gmail.com</a>
t: @hpcjoe
w: <a class="moz-txt-link-freetext" href="https://scalability.org">https://scalability.org</a>
g: <a class="moz-txt-link-freetext" href="https://github.com/joelandman">https://github.com/joelandman</a>
l: <a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/joelandman">https://www.linkedin.com/in/joelandman</a></pre>
</body>
</html>