Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
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 '12 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 '12 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 '12 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 '12 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 '12 at 3:23
show 2 more comments

1 Answer

up vote 4 down vote accepted

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!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.