由于磁盘故障，我们最近重新安装了服务器，现在我们遇到了调整terminal大小的问题。 我们安装了Debian 6.0.6。
症状
当您调整terminal的大小时，没有基于ncurses的应用程序（testing：ytalk，irssi，screen，tmux，某些ncurses示例应用程序）似乎正确resize。 屏幕通常是空白的。 在应用程序中强制重绘将使用旧的terminal大小重绘。
当在bash（4.1.5（1））提示符下调整窗口大小时，COLUMNS和LINESvariables永远不会更新。
诊断
试图用bash来捕获SIGWINCH，似乎从来没有收到过。 这已经过testing：
trap 'touch /home/user/sigwinch' SIGWINCH trap 'touch /home/user/sigusr1' SIGUSR1 kill -s SIGWINCH $$ kill -s SIGUSR1 $$ 哪个应该已经在我的主目录中创build了这两个文件。 它只创build/home/user/sigusr1 。
试图kill -s SIGWINCH $$不会导致$ COLUMNS / $ LINESvariables的更新。
启用checkwinsize （ shopt -s checkwinsize ）将导致bash在从任何应用程序返回时（如预期）更新$ COLUMNS / $ LINES。 在启用checkwinsize的terminal重新resize后，会导致以下情况：
$ echo $COLUMNS ; ls > /dev/null ; echo $COLUMNS 72 107
改变我的loginshell到tcsh之类的东西，并尝试调整terminal的大小，就像我testing过的其他盒子上的bash一样。
我试图删除我的.bashrc，它什么也没做。 对于其他几个用户来说，这个问题在PuTTY和Linux机器的某种types的rxvt型terminal中都有不同的configuration。
strace的
我在bash上运行strace，并尝试调整terminal的大小，没有任何事情发生（打印提示后，它立即被read呼叫阻塞）。
我打空回来，bash做了一大堆东西。 我认为相关的产出是:( 完整的 ）
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,
根据我的理解，这显示了bash：（我可能会很可怕地误解了这一点，我在这里摆脱了我的观点）。
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.
在没有这些问题的盒子（Ubuntu，bash 4.2.24（1））上执行相同的strace导致：
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,
题
到底是怎么回事，为什么我的打击破了？ 🙁
我猜测可能只是一个选项，默认情况下，谷歌的几个小时没有出现任何结果。
任何帮助和/或指针，不胜感激。 这真是令人沮丧。
谢谢。
一些东西一直在窃听我关于strace输出。 也就是说，当bash开始的时候，好像SIGWINCH已经被屏蔽了。 不能确定，不明白它吐出来的一半，但是在这一点上肯定值得一些探索。
我从tcsh shell运行strace -o strace_file bash -l ，问题不存在。 bash从来没有掩盖过SIGWINCH。 当它掩盖它时，只是因为它试图恢复以前的面具。 那么最初的面具从哪里来？
还有更多的时间在Google上，还有一个新鲜的想法，我发现这篇文章提到aptitude有时会导致sshd被SIGWINCH屏蔽，然后它会被所有生成的进程inheritance到shell。
我试过ps axwwws （全部，分离，宽输出，信号）。 它显示了几个产生的sshd进程被SIGWINCH屏蔽。
服务器/监听进程（sshd本身）没有。 托pipe连接使用tcsh的进程也没有。 那部分让我感到困惑。 我猜测（再次，知道很less关于这一点）信号掩码是过程组广泛什么的，tcsh是在开始时重置它，这也影响了ssh。
所以，在一时兴起的时候，我用tcsh连接（得到一个没有SIGWINCH掩码的干净的术语），重新启动了ssh，把我的shell改回了bash …而且它工作正常！ 一切都恢复正常了！
据我所知aptitude还没有运行在这个盒子上，并且ssh已经重新启动了几次configuration更改。 尽pipe如此，在面具的某处却掩盖了一切，像一种不好的疾病。
要识别相同的问题，请运行ps axwwws | grep sshd ps axwwws | grep sshd并寻找与第二个长列（ BLOCKED ）的sshd进程已设置0x8000000。 这是SIGWINCH。 就像是：
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
要解决它（可能不是最好的解决scheme，为我工作）：
$ 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
它是固定的。
干杯!
尝试这个。 做
bash$ shopt -s checkwinsize
在你的shell中，然后调整你的terminal窗口。