[SOLVED] Terminal emulators break occasionally, requiring "reset"

ezacaria · 2021-01-04 17:01:27

I've experienced this sporadically for quite some time, but today it just got on my nerves

Sometimes when doing chains of cat, grep/egrep, tail, head, less, etc., the terminal emulator stops displaying the typed characters. The only thing that seems to help is doing couple of ctrl-c and then enter the "reset" command.

I normally use the xfce4-terminal (either in a desktop machine or a remote server via tigervnc), and it may happen in both. Today, I tried other terminals (e.g., kitty, qterminal, urxvt, konsole) and I stumble on the issue with good likelihood within some 10 commands.

The source data can be around 500 MB and I do not recall having problems with small files. However, it may be that the offending command ends in "| head -n 5", suggesting that no stress comes to the terminal's input buffer. I tried launching urxvt from another terminal, but no messages appeared when the problem came up.

Any ideas on how to isolate where the problem is? I use XFCE4 with the compositor disabled. Everything else seems to work normally.

Last edited by ezacaria (2021-01-05 08:29:55)

Morn · 2021-01-04 18:31:42

What kind of data are you piping exactly? If your input contains a Ctrl-S character that would pause terminal output...

ezacaria · 2021-01-04 18:51:53

It is all ASCII characters, there should be no Ctrl-S present - apart from the possibility of some random bit flips.

In any case, the terminal stops echoing what I type, but it does not seem to be fully paused - the output of other commands may still come through even if I cannot see what I type.

Thanks!

karabaja4 · 2021-01-04 19:45:42

Are you using complex and/or colored PS1? Try setting it to something simple and check if the problem still occurs.

ezacaria · 2021-01-04 20:20:24

The PS1 is quite plain ('[\u@\h \W]\$ ').
I tried with a static '$ ' and it still happened after some 15 attempts

ezacaria · 2021-01-04 20:57:21

I tried Alacritty and was getting happy but soon it happened again.

Another thing I noticed is that after the terminal stops displaying what I type, the "Enter" key does not trigger new lines (i.e., where the PS1 would be stacking vertically). It still works so that I can type a command, hit enter, and see the output.

I do not see anything relevant in the journal. I wonder if there could be a debugging build of some terminal, which could tell where it tripped?

V1del · 2021-01-04 21:12:17

Are you using a non-monospace terminal font?

jasonwryan · 2021-01-04 21:12:22

Post your shell and environment conf files.

ezacaria · 2021-01-05 08:27:29

Thanks for the answers. I believe that I isolated the problem.

My personal preference is to clear the terminal's scroll-back buffer and screen at the same time. Since I find myself doing that often, I bind it to Ctrl-l in my Bash configuration:

bind -x '"\C-l":clear;echo -ne "\033c"'

I set this configuration years ago and hardly ever thought about it afterwards. It works on different terminals and also under cygwin.

After some experimentation and looking at Alacritty's debugging trace, it seems that the problem relates to the usage of the so-bound Ctrl-l.
I removed it, and the problem has not shown up so far.

I still do not know what is it in this "ESC-c" sequence is causing the trouble. I probably got the hint from a Stack Overflow thread (like like this one or something older). I did, however, notice some changes in Alacritty's traces after the problem appears.

This is the response to pressing "Enter" when Alacritty has fallen into the abnormal state:

[2021-01-05 08:16:06.897376174] [TRACE] [alacritty_terminal] Unsetting mode: BracketedPaste
[2021-01-05 08:16:06.897397394] [TRACE] [alacritty_terminal] Carriage return
[2021-01-05 08:16:06.897404962] [TRACE] [alacritty_terminal] Setting mode: BracketedPaste

And after the problem was solved by "reset", 5 lines per event show up rather than 3 (this is also the normal behaviour after startup).

[2021-01-05 08:17:33.033331763] [TRACE] [alacritty_terminal] Carriage return
[2021-01-05 08:17:33.033407163] [TRACE] [alacritty_terminal] Linefeed
[2021-01-05 08:17:33.033437854] [TRACE] [alacritty_terminal] Unsetting mode: BracketedPaste
[2021-01-05 08:17:33.033460436] [TRACE] [alacritty_terminal] Carriage return
[2021-01-05 08:17:33.033485739] [TRACE] [alacritty_terminal] Setting mode: BracketedPaste

It seems that some of the input goes missing, although it is still captured because I can type commands and the shell reacts to them even if they are not displayed while typed.

I am thinking of replacing the ESC-c with

bind -x '"\C-l":clear;tput reset'

which is also very fast.

Anyways, I think we can close this topic.

Thanks!

PS: the font is Monospace regular in xfce4-terminal and DejaVuSansMono.ttf used as default by Alacritty. I did not find anything out of the ordinary in my env/configuration files aside from the Ctrl-l binding

Arch Linux

#1 2021-01-04 17:01:27

[SOLVED] Terminal emulators break occasionally, requiring "reset"

#2 2021-01-04 18:31:42

Re: [SOLVED] Terminal emulators break occasionally, requiring "reset"

#3 2021-01-04 18:51:53

Re: [SOLVED] Terminal emulators break occasionally, requiring "reset"

#4 2021-01-04 19:45:42

Re: [SOLVED] Terminal emulators break occasionally, requiring "reset"

#5 2021-01-04 20:20:24

Re: [SOLVED] Terminal emulators break occasionally, requiring "reset"

#6 2021-01-04 20:57:21

Re: [SOLVED] Terminal emulators break occasionally, requiring "reset"

#7 2021-01-04 21:12:17

Re: [SOLVED] Terminal emulators break occasionally, requiring "reset"

#8 2021-01-04 21:12:22

Re: [SOLVED] Terminal emulators break occasionally, requiring "reset"

#9 2021-01-05 08:27:29

Re: [SOLVED] Terminal emulators break occasionally, requiring "reset"

Board footer