Bug 152522

This problem might be connected to bug #152101 although I am not certain yet.

init does not write to any terminal.

I'll try again with B5.

Beside this: Do you have an environment variable "CONSOLE"
in your environment?  If so try to unset CONSOLE before
running shutdown.

It was an standard installation without any change to the environment. Cannot check this atm, but as soon as B5 is running I will. As mentioned this happened with B3 already (when I first noted it).

OK I was able to reproduce this with Beta6 and there is no $CONSOLE variable in the environment.

OK let's rewrite the topic a little. We know now that the actual output (printing an '\n') is done by the shell, after it receives and reads some strange input from an (yet) unknown process. This does not happen at a text console and does not happen when commanding `reboot -r now'. And it does also not happen with another shell, so this seems to be a problem with bash. Updating to the latest build with some fixed line-warp issues in libreadline unfortunately did not solve the problem. I'll attached a backtrace of the xterm we tried this on.

Created attachment 71437 [details]
backtrace of the used xterm

Beside this the problem is a nasty one bbut it does _not_
crash the system nor break the reboot or halt the system.
Therefore this is IMHO a minor problem which can resolved
if I found more free time for this problem.

Remark: the official interface for halt/reboot/powerdown/single user mode
is the call of shutdown and not of init.  With this is works as it should.

This is really resistant, it's fine with me closing it with RESO->LATER. There is also a chance it vanishes with an upcoming release. I will keep track of it.

Hmm ... the interesstin question is: Which program or which kernel part
is flooding stdin of the bash with Carriage Return's and why does this
not happen if shutdown is calling init.

Just found by Max: `chvt 1' does the same as `init 6'.  To reproduce this
open an xterm or KDE konsole, become super user, do a Ctrl-l to be at the
very first line and then execute the command

           chvt 1

after you have been switched to the first virtual console, switch back with
(Ctrl-)Alt-F7.  Btw: even the tcsh does this but you have todo, after su and
starting a tcsh as root, the chvt command and switching back twice. This was
found by me by trail and error.  The question is: who or what is feeding the
file descriptors of the bash (fd == 0) and the tcsh (fd == 16) with CR or NL
depending on the tty settings.

Just to note: the final cause for the newlines is the ioctl VT_ACTIVATE.
IMHO there is a problem in the console/tty driver of the kernel as shown
by a hacked chvt.c.

OK just to be noted if one execute

          xset r off

in other word disable the autorepeat of the Xserver, it does not happen. 
This leads me to the assumption that we see a race condition here in
which the Xserver sees the `Enter key is pressed' but never but is missed
`Enter key is released' due to the fact that the Xserver does not get
a time slice for doing this. Therefore a `sleep 1; chvt 1' will not scroll.

Egbert?  Is there a way to use in the Xserver the handler for saving graphic
registers during a change virtual console to switch autorepeat temporary off?

The best solution would be to reset all pressed key states. I wonder why this hasn't happend with earlier versions.

Egbert, IIRC this bug exists since years ...

Yep and it was always closed with WONTFIX because no one has
an idea what was the cause of this problem.  Now we _know_ the
cause and we should fix this.  Beside this it depends on the
used Xserver and the power of the CPU and/or system in other
words a typical race condition.   If it is possible to reset
the pressed key states at a `chvt' then this should be done
within the core Xserver to avoid vendor specific problems.

This is a bug, not an enhancement. I'm setting this to normal.

Ping :)

Pong

JFYI, Matthias. This is a bugreport, which is assigned to Egbert/me or with Egbert/me in CC or reported by Egbert/me.

pin

Reassigning to Egbert.

At least minor.

Luc, could you have a look at this? It's rather annoying.

(In reply to comment #27 from Stefan Dirsch)
> Luc, could you have a look at this? It's rather annoying.
> 
???

I thought you might appreciate help here? Am I wrong? According to the comments you didn't look at this one yet.

Created attachment 209388 [details]
Proposed fix.

Eating up key events before going into the idle loop upon vt switch instead of after return should remedy this problem.
Stefan, does this do the job for you?

Hmm. I thought I could easily reproduce this issue with

  X :1 --> Ctrl-Alt-BS
  startx -- :1 --> Ctrl-Alt-BS
  xinit -- :1 --> Ctrl-Alt-BS

but now I can't any longer. :-( Werner, can you still? Michael Gross left the company a long time ago.

Stefan, start X, open a terminal, become root, type 'chvt 1' in the terminal, then enter. Once on the console switch back.
You should see a bunch of newlines without this patch.

I could finally reproduce this issue - and Egbert's patch fixes it! Applied.

Hm, this could also fix the infamous 'F7 to apps' bug. Egbert, your patch mentions 'HACK' several times, though from a first glance this looks like a very valid change.

I'd like to see that upstream, don't you agree? Maybe there is some side effect I didn't catch yet, though.