[Toybox] Ok, I've given myself a headache trying to understand this one.

[Rob Landley]

On 5/29/20 1:59 PM, Chet Ramey wrote:
> On 5/29/20 11:22 AM, Rob Landley wrote:
>> Running a mkroot build, it went:
>>
>> Compile toybox....scripts/make.sh: line 34: echo: write error: Resource
>> temporarily unavailable
>> ...scripts/make.sh: line 34: echo: write error: Resource temporarily unavailable
>> ............scripts/make.sh: line 34: echo: write error: Resource temporarily
>> unavailable
> 
> OK. Bash will do that if the write fails. It looks like fflush() fails and
> errno gets set to EAGAIN, which is only supposed to happen if the stdout fd
> is set to non-blocking. Bash doesn't set it that way, but the write returns
> -1/EAGAIN for some reason.

QEMU probably did something stupid to the tty and I forgot to type "reset".

(QEMU leaves the tty in weird states when it exits a lot of the time, and
mkroot.sh builds a system you run under qemu so edit/compile/test cycles happen
in the same terminal...)

First time I've seen that failure mode, but I may have updated the QEMU version
recently. Ok, close enough to an answer, I'm good for now. :)

>> I have no idea why the pipe or terminal it's outputting to is congested. There's
>> nothing in dmesg about it. But that's not the problem: I _assume_ bash's echo
>> won't output a message for that, and my echo should not output a message for
>> this either. (temporarily means it should retry? My echo hasn't set any signal
>> handlers and the default behavior is SA_RESTART?)
> 
> Bash doesn't mess with the signal behavior in that sense -- the only
> signals it sets SA_RESTART on are SIGCHLD, SIGWINCH, and, in previous
> versions, SIGTERM. None of that should be happening in a non-interactive
> shell.

Many moons ago had a problem where ctrl-Z on a "tar | gzip" pipeline would
corrupt the tarballs, and that's where writeall() and readall() came from (and
why xwrite() wraps writeall() which retries short writes).

I note that xprintf() does _not_ do that, and the _reason_ is Linux changed its
default behavior so it didn't do that no more.

See also the user mode linux "stuttering" problem I tracked down and fixed long
ago because -EAGAIN was getting retried twice (at two different levels):

http://lkml.iu.edu/hypermail/linux/kernel/0503.3/1756.html

> But I don't assume that -1/EAGAIN is the result of a signal. It could
> potentially be SIGCHLD, but bash sets that to SA_RESTART when it installs
> its handler.

Part of the reason I say "I break everything" is when something like this
happens it derails whatever I'm doing until I can track down the bug and kill
it. The bug running away and hiding on the refrigerator is NOT THE ANSWER.

Other people do not have "it did an unexplained thing, I must explain it" ruin
their afternoon. (It also makes them better about deadlines. And means they
interact with windows systems voluntarily.)

> Chet

Sorry to bug you. Thanks for the explanation,

Rob