I am getting an unusual error when trying to run Podman containers
using scrun on SLURM 23.11.3 (and 23.11.1 previously). In short, Podman
works when not configured to use scrun, but when configured to use scrun it
fails.

Podman gives this error:

scrun: fatal: Unable to request job allocation: Job cannot be submitted
without the current working directory specified.

The slurmctld logs show this error:

_slurm_rpc_allocate_resources: Job cannot be submitted without the current
working directory specified.

The scrun command does not appear to have a --chdir option so the working
directory must be detected automatically, and this appears to be failing.

       Perhaps someone has encountered this or a similar error before? If
anyone has seen this before I would love to hear about your experiences.


       A bit more detail in case anyone is interested. This is a two-node
test system with one head node and one compute node, both running Rocky
Linux 8.9. I have created /etc/containers/storage.conf and containers.conf
files which are identical to the ones in the SLURM Containers Guide except
that I set the rootless_storage_path to the same value as the graphroot in
storage.conf. When I get rid of the /etc/containers/containers.conf file I
can run containers on the head node. The backing store is ext4, though I
have tried NFS (which had other problems). I have tried the vfs and overlay
storage drivers but get the same results.

       On the SLURM side I created an oci.conf which is the same as the
"oci.conf example for crun using run (suggested)" from the SLURM Container
Guide. I'm using crun because I have forced cgroup v2 on both systems (
systemd.unified_cgroup_hierarchy=1 on the kernel cmdline) and crun seems to
support cgroup v2 better. I am using an scrun.lua which is similar to the
one in the scrun manual page with some paths modified for my setup.

       I should also mention that sbatch jobs run just fine and srun works
as well. the test cluster seems to be working fine in general.

-- 
Marcus Lauer
Systems Administrator
CETS Group, Research Support

Reply via email to