[slurm-users] pam_slurm_adopt and memory constraints?
juergen.salk at uni-ulm.de
Fri Jul 12 13:21:31 UTC 2019
I have configured pam_slurm_adopt in our Slurm test environment by
following the corresponding documentation:
I've set `PrologFlags=contain´ in slurm.conf and also have task/cgroup
enabled along with task/affinity (i.e. `TaskPlugin=task/affinity,task/cgroup´).
This is the current configuration in cgroups.conf:
PAM is enabled in /etc/ssh/sshd_config, i.e. `UsePAM yes´, which is
the default on RHEL7 anyway. SELinux is disabled on the system.
PAM configuration in /etc/pam.d/sshd (last two lines only):
# Authorize users that have a running job on node
account sufficient pam_slurm_adopt.so
account required pam_access.so nodefgroup
This does all work fine. Users can only log into a compute node if
they have at least one job running on it. Access is denied by
pam_slurm_adopt for all other users. When the user logs into a compute
node, the process environment is indeed "somewhat" adopted into the
external step of one of the running jobs. However *only* in terms of
$ sbatch --mem=2G job.slurm
Submitted batch job 357
$ scontrol show job 357 | grep BatchHost
$ ssh n1521
Last login: Fri Jul 12 14:43:19 2019 from XXXX
$ cat /proc/self/cgroup
Thus, the ssh session seems to be totally unconstrained by cgroups in
terms of memory usage. In fact, I was able to launch a test
application from the interactive ssh session that consumed almost all
of the memory on that node. That's obviously undesirable for a shared
user environment with jobs from different users running side by side
on one node at the same time.
I suppose this is nevertheless the expected behavior and just the way
it is when using pam_slurm_adopt to restrict access to the compute
nodes? Is that right? Or did I miss something obvious?
Thank you in advance for any comment.
PS: This is Slurm version 18.08.7 if that matters.
Scientific Software & Compute Services (SSCS)
Kommunikations- und Informationszentrum (kiz)
Telefon: +49 (0)731 50-22478
Telefax: +49 (0)731 50-22471
More information about the slurm-users