After a bit of back and forth with David, here is what I found:
- slurmd/srun used to buffer stdout internally in old versions (I know
for sure this happened in v2.6.2).
This buffering can be turned off using --unbuffered .
This is distinct from any buffering done on the user task.
- sometime after that slurm stopped buffering internally in all cases.
So --unbuffered became a no-op.
- In version 14.11, a patch was added to make --unbuffered allocate a
pty (exactly as the srun --pty option).
This caused the user task's stdlib to line buffer the output by
default. There are other side effects
to allocating a pty. "\n"s in the output stream is converted to
"\r\n". Signals are handled differently, I think.
So, if you are expecting to send/receive binary data, don't use
--unbuffered. In my opinion making
--unbuffered allocate a pty is very counter intuitive. If someone
needs a pty, they can use --pty.
For my use case, I just removed --unbuffered, and things work fine (ie,
no buffering, and no mangling of the stdout)
We always use fflush() or write(), so buffering in our code is not a
issue for us.
David mentioned that he would clarify the man page, if he decides to
keep the current behavior.
Thanks David for helping us resolve this issue.
Manu
On 02/25/2015 06:40 PM, Manu Thambi wrote:
Hi David,
The following commit (which is included in version 14.11.4) seems to make
stdout buffered when --unbuffered is passed in, which seems wrong.
We are using --unbufferred to get a binary pipe to the task.
If this change is intentional, then how can we get an unbuffered pipe
to the task?
Also, when --unbuffered is passed in, "\n" seems to be translated to
"\r\n" on Linux
machines.
Thanks.
Manu
-------------
commit 064cdb5eb6ea95ca23b1d5118b96dd04aa4c7e06
Author: David Bigagli <da...@schedmd.com>
Date: Thu Aug 14 17:39:41 2014
If using -u/unbuffered set the stdout of the task to be
line buffered.
--
Manu Thambi
Mesh Capital, LLC
201-918-4202
