Debian SSH-端末のサイズ変更がbashに登録されない


11

最近、ディスク障害のためにサーバーを再インストールしましたが、現在、端末のサイズ変更に問題があります。Debian 6.0.6をインストールしました。

症状

端末のサイズを変更すると、ncursesベースのアプリ(テスト済み:ytalk、irssi、screen、tmux、ncursesサンプルアプリケーションの一部)が正しくサイズ変更されないようです。通常、画面は空白になります。アプリケーションで強制的に再描画を行うと、古い端末サイズを使用して再描画されます。

bash(4.1.5(1))プロンプトでウィンドウのサイズを変更する場合、COLUMNSおよびLINES変数は更新されません。

診断

SIGWINCHをbashにトラップしようとすると、受信されないようです。これは以下でテストされました:

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変数は更新されません。

checkwinsizeshopt -s checkwinsize)を有効にすると、bashはアプリケーションからの戻り時に(予想どおり)$ COLUMNS / $ LINESを更新します。これは、checkwinsize有効にした端末のサイズを変更した後に次のようになります。

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

ログインシェルをtcshのようなものに変更し、ターミナルのサイズを変更しようとすると、期待どおりに動作します。他のボックスでのbashも同様です。

.bashrcを削除しようとしても何もしませんでした。この問題は、PuTTYとLinuxボックスのrxvtタイプの端末の両方でさまざまなbash構成を使用している他の複数のユーザーで発生しています。

痕跡

bashでstraceを実行し、ターミナルのサイズを変更しようとしましたが、何も起こりませんでした(readプロンプトを印刷した直後に呼び出しでブロックされたままになりました)。

私は空の行でリターンをヒットし、bashはたくさんのことをしました。関連すると思われる出力は:(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,

私の理解では、これは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))で実行されたこの同じ痕跡は、次の結果になりました。

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で何時間も何も表示されませんでした。

ヘルプやポインタは大歓迎です。これは本当にイライラします。

ありがとうございました。


あなたは最初のものではありません:lists.gnu.org/archive/html/bug-bash/2007-01/msg00084.htmlexec bash手で( もしそれがログインシェルではなくなった)場合、それはまだ誤動作していますか?そうでない場合はどうexec bash -lでしょうか(ログインシェルです)。その場合、ログインスクリプト(/etc/profile /etc/profile.d/ ~/.bash_profile ~/.profile)に問題がありますが、シェルにを通知しないようにするために、何を検索するように指示すればよいかわかりませんSIGWINCH
DerfK

両方exec bashexec bash -l同じ動作を示します。私はこれで私だけではないのは小さな慰めだと思います。しかし、これが何を引き起こすのかについて完全に混乱しています。coloは、新しくダウンロードしたDebianイメージから最小インストールをインストールしました。ローカルにインストールして、問題があるかどうかを確認する必要があります(他の人には発生しないように見えるので、何もないと仮定して)、実行中のシステムと比較し始めます。
NuclearDog

VMで新規インストールを行い、/ etcおよび/ usr内のすべてのファイルのmd5合計のリストを生成し、破損したシステムと比較しました。一見すると、明らかに間違っていることは何もありません。/etc/bash.bashrcすべての/etc/profileおよび/etc/profile.dファイルはクリーンインストールから変更されていません。bashのソース(apt-get source bash)をダウンロード./configureし、ソースを掘り下げる前に問題を絞り込むためのさまざまな引数で遊んでいます。
NuclearDog

私はbashからすべてのDebianパッチを除いてコンパイル--disable-readline --enable-minimal-config --disable-job-controlし、straceを実行して、どのファイルを使用したかを確認しopen、それらのファイルの名前をすべて変更してから、再度ログインしました。同じ問題。bash自体の構成の変更は、かなり確実に除外しました。
NuclearDog

GNUから直接取得したソースからコンパイルしたbash 3.2、4.1、4.2で同じ問題を再現しました。いくつかのバグのため、ジョブ制御なしで最小限の構成で4.2をコンパイルできませんでした(bashチームに報告されました)。これがいくつかのバージョンのbashで発生することを考えると、エラーは依存するライブラリの1つにある可能性があると信じ始めています。それに移ります。
NuclearDog

回答:


11

何かがstrace出力について私を悩ませていました。つまり、bashが起動したとき、すでにSIGWINCHがマスクされているように見えました。確かではありませんが、吐き出されたものの半分を理解していませんでしたが、この時点でいくつかの調査の価値がありました。

私はstrace -o strace_file bash -l、問題が存在しないtcshシェルから実行しました。bashはSIGWINCHをマスクしませんでした。マスクしていたのは、以前のマスクを復元しようとしたためでした。それで、最初のマスクはどこから来たのですか?

グーグルと新鮮な心でもう少し時間を過ごし、私はこの投稿で、aptitudeがSIGWINCHマスクでsshdを開始することがあり、生成されたすべてのプロセスによってシェルに直接継承されることを発見しました。

試しましたps axwwws(すべて、分離、ワイド出力、信号)。生成されたsshdプロセスのいくつかがSIGWINCHマスクされていることを示しました。

サーバー/リスニングプロセス(sshd自体)はしませんでした。また、tcshを使用した接続をホストしているプロセスも同様でした。その部分は私を混乱させます。信号マスクがプロセスグループ全体か何かであると推測しますが(これについてもほとんど知らないため)、tcshは開始時にリセットし、sshにも影響していました。

だから、気まぐれに、私はtcshに接続して(SIGWINCHマスクなしでクリーンな用語を取得するために)、sshを再起動し、シェルをbashに戻しました...そして、うまくいきました!すべてが正常に戻りました!

私の知る限り、このボックスではaptitudeが実行されておらず、構成の変更のためにsshが数回再起動されています。しかし、線に沿ったどこかで、マスクが入り込み、悪い病気のようなものすべてに感染しました。

同じ問題を認識するにはps axwwws | grep sshd、2番目の長い列(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

そしてそれは修正されました。

乾杯!


1

これを試して。行う

bash$ shopt -s checkwinsize

シェルで、ターミナルウィンドウのサイズを変更します。


2
ServerFaultへようこそ。ユーザーが数年前にこの問題を既に解決していることに気づきましたか?

1
bashの代わりにtcshを使用すると、回避策のように見えました。
gjvc
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.