Hi,

glibc does line buffering by default when connected to a terminal, and
block buffering otherwise. (see man setvbuf)

If you want to force line buffering in the client task, just making a call to
setlinebuf(stdout) is all that is needed. No explicit
fflush() is required. I guess this is what the original
bug report was about.

My understanding of --unbuffered is to control buffering of stdout
inside srun (not the client task).  The old code worked correctly
according to the old man page of srun. I am not sure what exactly
is accomplished by changing the behavior.

For now, as a work around, I removed the --unbuffered option
from srun command line, and that results
in an unbuffered stdout inside srun. (which is exactly the
opposite of how it should work).

Thanks.
Manu

On 03/05/2015 01:49 PM, David Bigagli wrote:

Hi,
can we see what script is broken? You may want to review #991 to get the full picture.


On 03/05/2015 09:19 AM, Pär Lindfors wrote:

Manu Thambi <[email protected]> writes:

The following commit (which is included in version 14.11.4) seems to
make
stdout buffered when --unbuffered is passed in, which seems wrong.
...

"seems wrong" is an understatement. I honestly thought I did not read
your e-mail correctly the first time.

This is completely messed up. Please SchedMD, commit
064cdb5eb6ea95ca23b1d5118b96dd04aa4c7e06 needs to be reverted!

If no option like this had existed before, then due to the principle of
least surprise it would be quite bad to name it "--unbuffered" when what
it does is to set line buffered output.

Now the situation is a lot worse. The -u/--unbuffered option to srun
have been around for more than 10 years (added in commit 159e591b,
2003-04-08, slurm 0.2.0) and have always set stdout to be unbuffered. In
14.11 it changes to do the opposite, breaking any job script or utility
made during those years that specify "srun -u" because they actually
need unbuffered stdout.

We have such scripts, and I have just verified that they are indeed
broken on Slurm 14.11. We just took our first cluster running 14.11 into
production this week, so probably not many users have run into this yet.

Regards,
Pär Lindfors, NSC



Reply via email to