☰

Debian SSH - 调整终端大小不会在 bash 中注册

tag-icon • tag-icon debian bash term
Debian SSH - 调整终端大小不会在 bash 中注册

由于磁盘故障，我们最近重新安装了服务器，现在我们在调整终端大小时遇到​​了问题。我们安装了 Debian 6.0.6。

症状

当您调整终端大小时，似乎没有基于 ncurses 的应用程序（已测试：ytalk、irssi、screen、tmux、一些 ncurses 示例应用程序）能够正确调整大小。屏幕通常最后会变成空白。在应用程序中强制重绘将使用旧的终端大小进行重绘。

在 bash (4.1.5(1)) 提示符下调整窗口大小时，COLUMNS 和 LINES 变量永远不会更新。

诊断

尝试在 bash 中捕获 SIGWINCH，但似乎从未收到。已使用以下方法进行了测试：

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

它应该在我的主目录中创建两个文件。但它只创建了/home/user/sigusr1。

尝试kill -s SIGWINCH $$不会导致 $COLUMNS/$LINES 变量的更新。

启用checkwinsize( shopt -s checkwinsize) 将导致 bash 在从任何应用程序返回时更新 $COLUMNS/$LINES（如预期）。在checkwinsize启用后调整终端大小后，这会导致以下情况：

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

将我的登录 shell 更改为 tcsh 之类的东西并尝试调整终端大小，一切如预期，我在其它机器上测试的 bash 也是如此。

我尝试删除 .bashrc，但什么也没发生。其他几位用户在 PuTTY 和 Linux 机器上的某种 rxvt 类型终端中使用不同的 bash 配置时也遇到了这个问题。

斯特拉斯

我在 bash 上运行了 strace，并尝试调整终端大小，但没有任何反应（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.

在没有这些问题的机器上执行相同的 strace (Ubuntu，bash 4.2.24(1)) 结果是：

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,

问题

到底发生了什么事？为什么我的 bash 坏了？:(

我猜想可能只是某个地方的默认选项，可以实现一些意想不到的事物，但在 Google 上搜索了几个小时却一无所获。

非常感谢任何帮助和/或指点。这真是令人沮丧。

谢谢。

答案1

strace 输出中有些东西一直困扰着我。也就是说，当 bash 启动时，似乎已经屏蔽了 SIGWINCH。不能确定，我不明白它输出的一半是什么，但此时肯定值得探索一下。

我strace -o strace_file bash -l从 tcsh shell 运行，问题不存在。bash 从未屏蔽过 SIGWINCH。当它屏蔽它时，只是因为它试图恢复之前的掩码。那么初始掩码来自哪里？

在 Google 上花了更多时间，以清醒的头脑，我发现这个帖子其中提到，aptitude 有时会导致 sshd 以 SIGWINCH 屏蔽启动，然后它将被所有生成的进程直接继承到 shell。

我尝试了ps axwwws(all, detached, wide output, signals)。结果显示，生成的几个 sshd 进程都屏蔽了 SIGWINCH。

服务器/监听进程（sshd 本身）没有。托管使用 tcsh 的连接的进程也没有。这部分让我很困惑。我猜（再次强调，我对这些了解甚少）信号掩码是进程组范围的，或者其他什么，tcsh 在启动时重置了它，这也影响了 ssh。

因此，我一时兴起，用 tcsh 连接（以获得没有 SIGWINCH 掩码的干净术语），重新启动 ssh，将 shell 改回 bash... 成功了！一切恢复正常！

据我所知，此机器上没有运行过 aptitude，并且 ssh 已重新启动几次以进行配置更改。然而，不知从何时起，掩码侵入了系统，并像恶性疾病一样感染了一切。

要识别相同的问题，请运行ps axwwws | grep sshd并查找第二列长 ( BLOCKED) 已设置 0x8000000 的 sshd 进程。这是 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

要修复它（可能不是最好的解决方案，但对我有用）：

$ 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

并且已经修复。

干杯!

答案2

尝试一下。

bash$ shopt -s checkwinsize

在你的 shell 中，然后调整你的终端窗口的大小。

相关内容