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.


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.


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

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.


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,


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.

  • You're not the first one: lists.gnu.org/archive/html/bug-bash/2007-01/msg00084.html If you exec bash by hand (so it's no longer a login shell) does it still misbehave? If not, what about exec bash -l (so it's a login shell)? If so, then something's up with your login scripts (/etc/profile /etc/profile.d/ ~/.bash_profile ~/.profile), but I don't even know what to tell you to be looking for that can tell the shell not to SIGWINCH.
    – DerfK
    Nov 26, 2012 at 22:40
  • Both exec bash and exec bash -l exhibit the same behaviour. I suppose it's a small consolation that I'm not alone in this. I'm thoroughly confused as to what would cause this, though. The colo installed a minimal install from a freshly downloaded Debian image. I'll have to try installing locally and see if there's any issues and (assuming none, since this appears to not happen for other people), start comparing to the running system.
    – NuclearDog
    Nov 27, 2012 at 1:04
  • I did a fresh install in a VM, generated a list of md5 sums of all files in /etc and /usr and compared against the broken system. At a quick glance, I can't see anything obviously wrong. /etc/bash.bashrc and all of the /etc/profile and /etc/profile.d files are unchanged from a clean install. I've downloaded the bash source (apt-get source bash) and am playing with various arguments to ./configure to try and narrow the problem down before I dig into the source.
    – NuclearDog
    Nov 27, 2012 at 2:10
  • I compiled bash minus all Debian patches with --disable-readline --enable-minimal-config --disable-job-control, ran an strace to see which files it open'd, renamed all those files, then logged in again. Same issue. I've fairly definitely ruled out any configuration changes with bash itself.
    – NuclearDog
    Nov 27, 2012 at 2:24
  • I've replicated the same issue with bash 3.2, 4.1 and 4.2 compiled from sources retrieved directly from GNU. I was unable to compile 4.2 without job control and with minimal config due to some bugs (reported to the bash team). Given that this occurs with several version of bash, I'm beginning to believe that the error may lie with one of the libraries it depends on. Moving on to that.
    – NuclearDog
    Nov 27, 2012 at 3:23

2 Answers 2


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
$ 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.



Try this. Do

bash$ shopt -s checkwinsize

in your shell, then resize your terminal window.

  • 2
    Welcome to ServerFault. Did you notice that the user had already solved this issue years ago?
    – chicks
    Sep 30, 2017 at 17:45
  • 1
    Looked like a workaround to me using tcsh instead of bash.
    – gjvc
    Oct 1, 2017 at 4:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .