<div dir="ltr"><div class="gmail_quote">Hi Maria,</div><div class="gmail_quote"><br></div><div class="gmail_quote">seem related to srun's behavior around -u ; from the official doc<br><dt><b>-u</b>, <b>--unbuffered</b></dt><dd>
By default the connection between slurmstepd and the user launched application
is over a pipe. The stdio output written by the application is buffered
by the glibc until it is flushed or the output is set as unbuffered.
See <a href="https://slurm.schedmd.com/setbuf.html">setbuf</a>(3). If this option is specified the tasks are executed with
a pseudo terminal so that the application output is unbuffered. This option
applies to step allocations.
</dd></div><div class="gmail_quote"> </div><div class="gmail_quote">Hth <br></div><div class="gmail_quote">Tilman <br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Message: 2<br>
Date: Tue, 9 Feb 2021 15:47:12 -0800<br>
From: Maria Semple <<a href="mailto:maria@rstudio.com" target="_blank">maria@rstudio.com</a>><br>
To: Slurm User Community List <<a href="mailto:slurm-users@lists.schedmd.com" target="_blank">slurm-users@lists.schedmd.com</a>><br>
Subject: [slurm-users] Job Step Output Delay<br>
Message-ID:<br>
        <CAJON5fi+V6ok3TstSxJr=<a href="mailto:wj6%2B2rD2Yr736-%2BMpVaBY%2BpuGYFcA@mail.gmail.com" target="_blank">wj6+2rD2Yr736-+MpVaBY+puGYFcA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello all,<br>
<br>
I've noticed an odd behaviour with job steps in some Slurm environments.<br>
When a script is launched directly as a job, the output is written to file<br>
immediately. When the script is launched as a step in a job, output is<br>
written in ~30 second chunks. This doesn't happen in all Slurm<br>
environments, but if it happens in one, it seems to always happen. For<br>
example, on my local development cluster, which is a single node on Ubuntu<br>
18, I don't experience this. On a large Centos 7 based cluster, I do.<br>
<br>
Below is a simple reproducible example:<br>
<br>
loop.sh:<br>
#!/bin/bash<br>
for i in {1..100}<br>
do<br>
   echo $i<br>
   sleep 1<br>
done<br>
<br>
withsteps.sh:<br>
#!/bin/bash<br>
srun ./loop.sh<br>
<br>
Then from the command line running sbatch loop.sh followed by tail -f<br>
slurm-<job #>.out prints the job output in smaller chunks, which appears to<br>
be related to file system buffering or the time it takes for the tail<br>
process to notice that the file has updated. Running cat on the file every<br>
second shows that the output is in the file immediately after it is emitted<br>
by the script.<br>
<br>
If you run sbatch withsteps.sh instead, tail-ing or repeatedly cat-ing the<br>
output file will show that the job output is written in a chunk of 30 - 35<br>
lines.<br>
<br>
I'm hoping this is something that is possible to work around, potentially<br>
related to an OS setting, the way Slurm was compiled, or a Slurm setting.<br>
<br>
-- <br>
Thanks,<br>
Maria<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.schedmd.com/pipermail/slurm-users/attachments/20210209/3bffe170/attachment-0001.htm" rel="noreferrer" target="_blank">http://lists.schedmd.com/pipermail/slurm-users/attachments/20210209/3bffe170/attachment-0001.htm</a>><br>
<br>
</blockquote></div></div>