CCing putty@p.d.o because this makes the user-mode-linux example in
the psusan manpage not work.


Steps to reproduce:

Put the attached scripts "psusan-uml" and "psusan-uml-inside" in
a directory and make them executable.

Run ./psusan-uml in a terminal.

Wait for the inital "read(0, " (from strace cat) to appear.
Type something.


Observed behaviour:

Nothing happens.  The input is not read.  Pressing ^D will terminate
the session, but the inner cat never sees the input.


Expected behaviour:

cat reads what you type and you see it appear in strace, and be
echoed.


Workaround:

Arrange not to write anything into linux.uml until some output has
appeared.  That seems to work OK for me, leading me to think it's not
a general lossage bug, but only happens if there is input to be read
when linux.uml starts up its consoles.


Notes:

Commenting out "echo initial" makes it work, showing that this is a
race.

The |cat at the end is because linux.uml sets the fds it is using for
a console to nonblocking.  cat objects to that.  So we pipe the stdout
too, so that linux.uml does not set the actual tty to nonblocking.

I repro'd this on sid, but I ran reportbug in my buster environment.
I forgot to change the version in the report.

Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

FWIW, I've pushed to PuTTY main today a patch that adds a bug workaround
flag for this kind of thing. Now the PuTTY client tools can be manually
configured to delay sending their SSH (or psusan) greeting until after
they see the greeting from the other end.

So, in that particular use case of UML, this can be worked around.

Cheers,
Simon

991958@bugs.debian.org