3

On one of our servers, whenever I kill a process with Ctrl-C (e.g. to terminate a tail -f process), my input to bash is not printed anymore. I can blindly type reset, which solved the situation, but it is very inconvenient.

I would like that killing a process with Ctrl-C would not cause this problem. Do you have any hints?

EDIT: some more information, as requested

The server is running Suse enterprise, with the kernel 2.6.32. The bash version we have installed is

GNU bash, version 3.2.51(1)-release (x86_64-suse-linux-gnu)

Concerning tail, it is

tail (GNU coreutils) 6.12

My current terminal emulator is konsole, but the same happened with a number of other emulators, including GNOME terminal and terminator.

Improve this question
10
  • That is not normal behavior. Please edit your question and include any information that might help. For example: what is your OS? What is your terminal emulator? Does this only happen to you or does it affect all users of the machine? Does it only happen when running bash or with all shells? Commented Mar 24, 2015 at 9:19
  • @terdon: Actually I've had this with some programs and scripts during repository conversion preparations and it was quite consistent. I think some programs simply do not clean up as needed at Ctrl+C. Commented Mar 24, 2015 at 9:21
  • @0xC0000022L OK, but tail -f? I, at least, have never had an issue with that. Commented Mar 24, 2015 at 9:22
  • @terdon: yeah, never had it with tail. Commented Mar 24, 2015 at 11:10
  • Um, I doubt this is the issue but please, please update your bash version. That one is still vulnerable to all sorts o security issues, including the recent shellshock vulnerability. Also, please clarify whether this happens with all programs or only some and tell us if this is only for your user or all. Commented Mar 24, 2015 at 11:13

1 Answer 1

Reset to default
0

Normally this only happens when you kill a program that had changed the TTY settings to turn off echo. e.g. mplayer / mpv, or a text editor. And even then, most well-behaved programs that modify the TTY catch signals, and put them back to how they found them before exitting from a SIGINT.

It's completely bizarre that you're seeing this kind of behaviour from tail. What happens if you type while tail is running? You should see echo, with the same kernel-provided line-editting that you get with cat > /dev/null.

Maybe you have something else running in the background that is messing with your TTY? Run tty to find out what tty you're on, then you can stty -a < /dev/that_tty from another shell to examine the state. (look for echo, rather than -echo).

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.