<div dir="ltr"><div>Matt,</div><div>  I saw a similar situation with a PBS job recently.</div><div>A process with is writing to disk cannot be killed (it is in S state). So the job ended but PBS logged that it could not kill the process.</div><div>I would look in detail at the slurm logs at the point where that job is being killed, and you might get some information.</div><div>I guess this depends on the method which Slurm uses to kill a job.</div><div><br></div><div>Of course this could be a completely different scanario.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 November 2017 at 14:55, Matt McKinnon <span dir="ltr"><<a href="mailto:matt@techsquare.com" target="_blank">matt@techsquare.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
I'm wondering if you've seen this issue around, I can't seem to find anything on it:<br>
<br>
We have an NVIDIA DGX-1 that we run SLURM on in order to queue up jobs on the GPU's there, but we're running into an issue:<br>
<br>
    1) launch a SLURM job (assume job id = 12345)<br>
<br>
    2) start a program that runs on GPUs and writes continuously to disk (e.g., to ~/test.txt)<br>
<br>
    3) kill the process in another terminal with the command scancel 12345<br>
<br>
You would see that although the job 12345 has been killed, the file ~/test.txt is still being written to, and that the GPU memory taken up by job 12345 is still not released.<br>
<br>
Have you seen anything like this?  Trying to figure out if it's a SLURM issue, or a GPU issue.  We're running SLURM 17.02.7.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Matt<br>
<br>
</font></span></blockquote></div><br></div>