Ticket 4220

Hello Marios,

I tried to reproduce the case in 17.02.4 and 17.02.7 but in all cases I always get the "Submited batch job xxx" message.

Can you please show me the contents of batch script "cmds" or try it with a simple one like this:

#!/bin/bash
#SBATCH --job-name=serial
#SBATCH --output=sl_%j.out
#SBATCH --error=sl_%j.err
#SBATCH --partition=debug
#SBATCH --time=00:01:00
sleep 10
hostname

I used:

$] sbatch serial.sh

and

$] sbatch -W serial.sh

What shell do you use? Is it possible that your environment/prompt is modified in some way?

BR,
Felip M

I just realized that this issue arises only if I redirect stdout to a 
file. Try this:

cmds:
#!/bin/bash
#SBATCH --job-name=serial
#SBATCH --partition=debug
#SBATCH --time=00:01:00
sleep 10
hostname

 > strace sbatch -vv -W cmds 1> out 2> err
 > strace sbatch -vv cmds 1> out2 2> err2

Then "vimdiff err err2" and look for "Submitted". You will see that in 
both cases it appears right before the exit (which is too late for the 
-W case).

Now try again, but remove the stdout redirection:
 > strace sbatch -vv -W cmds 2> err
 > strace sbatch -vv cmds 2> err2

vimdiff err err2 again, and you will see that now "Submitted" in the -W 
case now appears at the top.

So it is the redirection changing things around, not the -W flag per se. 
Very interesting.

On 10/4/2017 6:49 AM, bugs@schedmd.com wrote:
> Felip Moll <mailto:felip.moll@schedmd.com> changed bug 4220 
> <https://bugs.schedmd.com/show_bug.cgi?id=4220>
> What 	Removed 	Added
> CC 		felip.moll@schedmd.com
> Assignee 	support@schedmd.com 	felip.moll@schedmd.com
>
> *Comment # 1 <https://bugs.schedmd.com/show_bug.cgi?id=4220#c1> on bug 
> 4220 <https://bugs.schedmd.com/show_bug.cgi?id=4220> from Felip Moll 
> <mailto:felip.moll@schedmd.com> *
> Hello Marios,
>
> I tried to reproduce the case in 17.02.4 and 17.02.7 but in all cases I always
> get the "Submited batch job xxx" message.
>
> Can you please show me the contents of batch script "cmds" or try it with a
> simple one like this:
>
> #!/bin/bash
> #SBATCH --job-name=serial
> #SBATCH --output=sl_%j.out
> #SBATCH --error=sl_%j.err
> #SBATCH --partition=debug
> #SBATCH --time=00:01:00
> sleep 10
> hostname
>
> I used:
>
> $] sbatch serial.sh
>
> and
>
> $] sbatch -W serial.sh
>
> What shell do you use? Is it possible that your environment/prompt is modified
> in some way?
>
> BR,
> Felip M
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You reported the bug.
>

Created attachment 5331 [details]
sbatch block to line buffered when no tty

Hi Marios,

The issue here is that block-buffering is used on pipes vs. line-buffering on interactive terminals. When a stream is fully buffered, characters are intended to be transmitted to or from the host environment as a block when a buffer is filled. The operating system defines the size of the buffer.

sbatch.c uses block-buffering by default so you when using pipes/redirects you will see the output once the buffer is full.

I created a patch to change to line-buffering when no tty is detected, feel free to apply it to sbatch.c.

This modification will not be included in 17.02.

More background in Online C11 standard, 7.21.3/3 and 7.21.3/7: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Marios,

The patch will be included in release 17.11 and up, but if you want to use in 17.02 you will have to use a separate sbatch.

Best regards
Felip M