Recentemente abbiamo reinstallato il nostro server a causa di un errore del disco e ora abbiamo un problema con il ridimensionamento dei terminali. Abbiamo installato Debian 6.0.6.
Sintomi
Quando si ridimensiona un terminale, nessuna app basata su ncurses (testata: ytalk, irssi, screen, tmux, alcune delle applicazioni di esempio ncurses) sembra ridimensionare correttamente. Lo schermo in genere finisce vuoto. Forzare un ridisegno nell'applicazione verrà ridisegnato utilizzando le dimensioni del vecchio terminale.
Quando si ridimensiona una finestra al prompt bash (4.1.5 (1)), le variabili COLONNE e LINEE non vengono mai aggiornate.
Diagnostica
Tentando di intrappolare SIGWINCH in bash, sembra che non venga mai ricevuto. Questo è stato testato con:
trap 'touch /home/user/sigwinch' SIGWINCH
trap 'touch /home/user/sigusr1' SIGUSR1
kill -s SIGWINCH $$
kill -s SIGUSR1 $$
Che avrebbe dovuto creare entrambi i file nella mia home directory. Ha solo creato /home/user/sigusr1
.
Provare a kill -s SIGWINCH $$
non provoca un aggiornamento delle variabili $ COLUMNS / $ LINES.
Abilitando checkwinsize
( shopt -s checkwinsize
), bash aggiornerà $ COLUMNS / $ LINES al ritorno da qualsiasi applicazione (come previsto). Ciò porta a quanto segue dopo il ridimensionamento di un terminale con checkwinsize
abilitato:
$ echo $COLUMNS ; ls > /dev/null ; echo $COLUMNS
72
107
Cambiare la mia shell di login in qualcosa come tcsh e tentare di ridimensionare il terminale funziona come previsto, così come bash su altre caselle che ho testato.
Ho provato a rimuovere il mio .bashrc e non ha fatto nulla. Questo problema si verifica per molti altri utenti con diverse configurazioni bash sia in PuTTY che in una sorta di terminale di tipo rxvt da una scatola Linux.
strace
Ho eseguito strace su bash e ho provato a ridimensionare il terminale, non è successo nulla (è rimasto bloccato su una read
chiamata immediatamente dopo aver stampato il prompt).
Ho colpito return su una riga vuota e bash ha fatto un sacco di cose. L'output che ritengo rilevante è: ( 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,
Il che dimostra bash, per la mia comprensione: (Potrei essere terribilmente frainteso questo. Sono molto fuori dal mio elemento qui.)
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.
La stessa sequenza eseguita su una scatola senza questi problemi (Ubuntu, bash 4.2.24 (1)) ha comportato:
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,
Domanda
Cosa diavolo sta succedendo e perché la mia bash è rotta? :(
Immagino che ci sia probabilmente solo un'opzione da qualche parte che è passata per impostazione predefinita a qualcosa di inaspettato, ma ore su Google non hanno prodotto nulla.
Qualsiasi aiuto e / o suggerimenti sono molto apprezzati. Questo è davvero frustrante.
Grazie.
exec bash
ed exec bash -l
esibiscono lo stesso comportamento. Suppongo sia una piccola consolazione che non sono solo in questo. Sono profondamente confuso su ciò che potrebbe causare questo, però. Il colo ha installato un'installazione minima da un'immagine Debian appena scaricata. Dovrò provare a installare localmente e vedere se ci sono problemi e (supponendo che nessuno, dal momento che ciò non sembra accadere per altre persone), iniziare a confrontare con il sistema in esecuzione.
/etc/bash.bashrc
e tutti i file /etc/profile
e /etc/profile.d
rimangono invariati rispetto a un'installazione pulita. Ho scaricato bash source ( apt-get source bash
) e sto giocando con vari argomenti ./configure
per cercare di restringere il problema prima di scavare nel sorgente.
--disable-readline --enable-minimal-config --disable-job-control
, ho eseguito uno strace per vedere quali file fosse open
, ho rinominato tutti quei file, quindi ho effettuato nuovamente l'accesso. Stesso problema. Ho decisamente escluso qualsiasi cambiamento di configurazione con bash stesso.
exec bash
mano (quindi non è più una shell di login) si comporta ancora male? In caso contrario, che direexec bash -l
(quindi è una shell di accesso)? Se è così, allora c'è qualcosa che non va nei tuoi script di login (/etc/profile
/etc/profile.d/
~/.bash_profile
~/.profile
), ma non so nemmeno cosa dirti di cercare che possa dire alla shell di non farloSIGWINCH
.