Debian SSH - Resizing terminal does not register with bash

Question

We recently reinstalled our server due to a disk failure, and now we're having an issue with resizing terminals. We installed Debian 6.0.6.

Symptoms

When you resize a terminal, no ncurses-based apps (tested: ytalk, irssi, screen, tmux, some of the ncurses example applications) seem to resize correctly. The screen typically ends up blank. Forcing a redraw in the application will redraw using the old terminal size.

When resizing a window at a bash (4.1.5(1)) prompt, the COLUMNS and LINES variables are never updated.

Diagnostics

Attempting to trap the SIGWINCH in bash, it seems it is never being received. This was tested with:

trap 'touch /home/user/sigwinch' SIGWINCH
trap 'touch /home/user/sigusr1' SIGUSR1
kill -s SIGWINCH $$
kill -s SIGUSR1 $$

Which should have created both files in my home directory. It only created /home/user/sigusr1.

Trying to kill -s SIGWINCH $$ does not cause an update of the $COLUMNS/$LINES variables.

Enabling checkwinsize (shopt -s checkwinsize) will cause bash to update $COLUMNS/$LINES upon return from any application (as expected). This leads to the following after resizing a terminal with checkwinsize enabled:

$ echo $COLUMNS ; ls > /dev/null ; echo $COLUMNS
72
107

Changing my login shell to something like tcsh and attempting to resize the terminal works as expected, as does bash on other boxes I tested.

I tried removing my .bashrc and it did nothing. This problem is occurring for several other users with varying bash configurations in both PuTTY and some sort of rxvt-type terminal from a Linux box.

strace

I ran strace on bash and tried resizing the terminal, nothing came through (it remained blocked on a read call immediately after printing the prompt).

I hit return on an empty line, and bash did a whole bunch of stuff. The output I believe to be relevant is: (full strace)

1: rt_sigprocmask(SIG_SETMASK, [WINCH], NULL, 8) = 0
2: rt_sigaction(SIGWINCH, {0x80e2c20, [], SA_RESTART}, {0x809c310, [], 0}, 8) = 0
3: rt_sigprocmask(SIG_BLOCK, [INT], [WINCH], 8) = 0
4: write(2, "aa:~$ ", 6)                   = 6
5: rt_sigprocmask(SIG_SETMASK, [WINCH], NULL, 8) = 0
6: rt_sigprocmask(SIG_BLOCK, NULL, [WINCH], 8) = 0
7: read(0,

Which shows bash, to my understanding: (I could be horribly misunderstanding this. I'm way out of my element here.)

1: Disabling delivery of the SIGWINCH signal, when previously it was allowed.
2: Registering a handler for the SIGWINCH signal.
3: Masking some other combination of signals. As evidenced by line 5, this does not include SIGWINCH.
4: Printing the prompt.
5: Masking SIGWINCH, where previously nothing was blocked.
6: Masking the "union of null and SIGWINCH" which, to my understanding, would result in SIGWINCH being masked.
7: Waiting on input.

This same strace performed on a box without these issues (Ubuntu, bash 4.2.24(1)) resulted in:

1: rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
2: rt_sigaction(SIGWINCH, {0x49e320, [], SA_RESTORER|SA_RESTART, 0x7f7ef49f64c0}, {0x457880, [], SA_RESTORER, 0x7f7ef49f64c0}, 8) = 0
3: rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
4: write(2, "aaaaaaa:~$ ", 11)             = 11
5: rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
6: rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
7: read(0,

Question

What in the hell is going on and why is my bash broken? :(

I'm guessing there's probably just an option somewhere that defaulted to something unexpected, but hours on Google have turned up nothing.

Any help and/or pointers are greatly appreciated. This is really frustrating.

Thank you.

Answer 1

Something had been bugging me about the strace output. Namely that it seemed that when bash started, it seemed it already had SIGWINCH masked. Couldn't be sure, didn't understand half of what it was spitting out, but it was certainly worth some exploration at this point.

I ran strace -o strace_file bash -l from a tcsh shell, where the issue was not present. bash never masked SIGWINCH. When it was masking it, it was only because it was attempting to restore the previous mask. So where was the initial mask coming from?

Some more time on Google and a fresh mind and I found this post which mentioned that aptitude can sometimes cause sshd to be started with SIGWINCH masked, and that it will then be inherited by all the spawned processes straight down to the shell.

I tried ps axwwws (all, detached, wide output, signals). It showed several of the spawned sshd processes had SIGWINCH masked.

The server/listening process (sshd itself) did not. Nor did the processes which were hosting connections which used tcsh. That part is confusing to me. I'm guessing (again, knowing very little about any of this) that the signal mask is process-group wide or something, tcsh was resetting it on start, and that was affecting ssh as well.

So, on a whim, I connected in with tcsh (to get a clean term with no SIGWINCH mask), restarted ssh, changed my shell back to bash... And it worked! Everything's back to normal!

As far as I know aptitude has not been run on this box, and ssh has been restarted a few times for configuration changes. Somewhere along the line the mask made its way in, though, and infected everything like a bad disease.

To recognize the same issue, run ps axwwws | grep sshd and look for sshd processes with the second long column (BLOCKED) has 0x8000000 set. That's SIGWINCH. Something like:

   0 26425 0000000000000000 0000000008000000 0000000000001000 0000000180004003 Ss   ?          0:00 sshd: aa [priv]
1000 26430 0000000000000000 0000000008000000 0000000000001000 0000000180010000 S    ?          0:02 sshd: aa@pts/24

To fix it (possibly not the best solution, worked for me):

$ sudo apt-get install tcsh
[snip]
$ chsh -s /bin/tcsh
[connect in with a new connection, leave the old one open in case of any issues with tcsh]
$ sudo /etc/init.d/ssh restart

And it's fixed.

Cheers!

Answer 2

Try this. Do

bash$ shopt -s checkwinsize

in your shell, then resize your terminal window.