<div dir="ltr">Dear all,<br><br>Since the upgrade from Slurm 22.05 to 23.11.1 we are having problems with the communication between the slurmctld and slurmd processes.<br>We are running a cluster with 183 nodes and almost 19000 cores. Unfortunately some nodes are in a different network preventing full internode communication. A network topology and setting TopologyParam RouteTree have been used to make sure no slurmd communication happens between nodes on different networks.<br><br>In the new Slurm version we see the following issues, which did not appear in 22.05:<br><br>1. slurmd processes acquire many network connections in CLOSE-WAIT (or CLOSE_WAIT depending on the tool used) causing the processes to hang, when trying to restart slurmd.<br><br>When checking for CLOSE-WAIT processes we see the following behaviour:<br>Recv-Q Send-Q Local Address:Port Peer Address:Port Process <br>1 0 <a href="http://10.5.2.40:6818">10.5.2.40:6818</a> <a href="http://10.5.0.43:58572">10.5.0.43:58572</a> users:(("slurmd",pid=1930095,fd=72),("slurmd",pid=1930067,fd=72))<br>1 0 <a href="http://10.5.2.40:6818">10.5.2.40:6818</a> <a href="http://10.5.0.43:58284">10.5.0.43:58284</a> users:(("slurmd",pid=1930095,fd=8),("slurmd",pid=1930067,fd=8)) <br>1 0 <a href="http://10.5.2.40:6818">10.5.2.40:6818</a> <a href="http://10.5.0.43:58186">10.5.0.43:58186</a> users:(("slurmd",pid=1930095,fd=22),("slurmd",pid=1930067,fd=22))<br>1 0 <a href="http://10.5.2.40:6818">10.5.2.40:6818</a> <a href="http://10.5.0.43:58592">10.5.0.43:58592</a> users:(("slurmd",pid=1930095,fd=76),("slurmd",pid=1930067,fd=76))<br>1 0 <a href="http://10.5.2.40:6818">10.5.2.40:6818</a> <a href="http://10.5.0.43:58338">10.5.0.43:58338</a> users:(("slurmd",pid=1930095,fd=19),("slurmd",pid=1930067,fd=19))<br>1 0 <a href="http://10.5.2.40:6818">10.5.2.40:6818</a> <a href="http://10.5.0.43:58568">10.5.0.43:58568</a> users:(("slurmd",pid=1930095,fd=68),("slurmd",pid=1930067,fd=68))<br>1 0 <a href="http://10.5.2.40:6818">10.5.2.40:6818</a> <a href="http://10.5.0.43:58472">10.5.0.43:58472</a> users:(("slurmd",pid=1930095,fd=69),("slurmd",pid=1930067,fd=69))<br>1 0 <a href="http://10.5.2.40:6818">10.5.2.40:6818</a> <a href="http://10.5.0.43:58486">10.5.0.43:58486</a> users:(("slurmd",pid=1930095,fd=38),("slurmd",pid=1930067,fd=38))<br>1 0 <a href="http://10.5.2.40:6818">10.5.2.40:6818</a> <a href="http://10.5.0.43:58316">10.5.0.43:58316</a> users:(("slurmd",pid=1930095,fd=29),("slurmd",pid=1930067,fd=29))<br><br>The first IP address is that of the compute node, the second that of the node running slurmctld. The nodes can communicate using these IP addresses just fine.<br><br>2. slurmd cannot be properly restarted<br>[2024-01-18T10:45:26.589] slurmd version 23.11.1 started<br>[2024-01-18T10:45:26.593] error: Error binding slurm stream socket: Address already in use<br>[2024-01-18T10:45:26.593] fatal: Unable to bind listen port (6818): Address already in use<br><br>This is probably because of the processes being in CLOSE-WAIT, which can only be killed using signal -9.<br><br>3. We see jobs stuck in completing CG state, probably due to communication issues between slurmctld and slurmd. The slurmctld sends repeated kill requests but those do not seem to be acknowledged by the client. This happens more often in large job arrays, or generally when many jobs start at the same time. However, this could be just a biased observation (i.e., it is more noticeable on large job arrays because there are more jobs to fail in the first place).<br><br><div>4. Since the new version we also see messages like:<br>[2024-01-17T09:58:48.589] error: Failed to kill program loading user environment<br>[2024-01-17T09:58:48.590] error: Failed to load current user environment variables<br>[2024-01-17T09:58:48.590] error: _get_user_env: Unable to get user's local environment, running only with passed environment<br>The effect of this is that the users run with the wrong environment and can’t load the modules for the software that is needed by their jobs. This leads to many job failures.<br><br>The issue appears to be somewhat similar to the one described at: <a href="https://bugs.schedmd.com/show_bug.cgi?id=18561">https://bugs.schedmd.com/show_bug.cgi?id=18561</a><br>In that case the site downgraded the slurmd clients to 22.05 which got rid of the problems.<br>We’ve now downgraded the slurmd on the compute nodes to 23.02.7 which also seems to be a workaround for the issue.<br><br>Does anyone know of a better solution?<br><div><br></div><div>Kind regards,</div><div><br></div><div>Fokke Dijkstra</div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Fokke Dijkstra <a href="mailto:f.dijkstra@rug.nl" target="_blank"><f.dijkstra@rug.nl></a>
<br>Team High Performance Computing</div><div dir="ltr">Center for Information Technology, University of Groningen
<br>Postbus 11044, 9700 CA Groningen, The Netherlands
<br><br>
</div></div></div></div></div></div>