Wir haben unseren Server kürzlich aufgrund eines Festplattenfehlers neu installiert und haben jetzt ein Problem mit der Größenänderung von Terminals. Wir haben Debian 6.0.6 installiert.
Symptome
Wenn Sie die Größe eines Terminals ändern, scheinen keine auf ncurses basierenden Apps (getestet: ytalk, irssi, screen, tmux, einige der ncurses-Beispielanwendungen) die Größe korrekt zu ändern. Der Bildschirm bleibt normalerweise leer. Wenn Sie ein erneutes Zeichnen in der Anwendung erzwingen, wird das Zeichnen mit der alten Terminalgröße neu erstellt.
Wenn Sie die Größe eines Fensters an einer Bash-Eingabeaufforderung (4.1.5 (1)) ändern, werden die Variablen COLUMNS und LINES niemals aktualisiert.
Diagnose
Beim Versuch, das SIGWINCH in Bash zu fangen, scheint es, dass es niemals empfangen wird. Dies wurde getestet mit:
trap 'touch /home/user/sigwinch' SIGWINCH
trap 'touch /home/user/sigusr1' SIGUSR1
kill -s SIGWINCH $$
kill -s SIGUSR1 $$Welches sollte beide Dateien in meinem Home-Verzeichnis erstellt haben. Es wurde nur erstellt /home/user/sigusr1.
Der Versuch, kill -s SIGWINCH $$dies zu tun , führt nicht zu einer Aktualisierung der Variablen $ COLUMNS / $ LINES.
Wenn Sie checkwinsize( shopt -s checkwinsize) aktivieren, aktualisiert bash $ COLUMNS / $ LINES bei Rückkehr von einer beliebigen Anwendung (wie erwartet). Dies führt nach dem Ändern der Größe eines Terminals mit checkwinsizeaktiviertem Status zu Folgendem :
$ echo $COLUMNS ; ls > /dev/null ; echo $COLUMNS
72
107Das Ändern meiner Login-Shell in etwas wie tcsh und der Versuch, die Größe des Terminals zu ändern, funktioniert wie erwartet, ebenso wie das Bash auf anderen von mir getesteten Boxen.
Ich habe versucht, meine .bashrc zu entfernen, aber es hat nichts getan. Dieses Problem tritt bei mehreren anderen Benutzern mit unterschiedlichen Bash-Konfigurationen sowohl in PuTTY als auch in einer Art Terminal vom Typ rxvt von einer Linux-Box auf.
strace
Ich habe strace on bash ausgeführt und versucht, die Größe des Terminals zu ändern. Es ist nichts durchgekommen (es blieb bei einem readAnruf unmittelbar nach dem Drucken der Eingabeaufforderung blockiert ).
Ich drückte auf einer leeren Zeile die Eingabetaste und Bash machte eine ganze Reihe von Sachen. Die Ausgabe, die ich für relevant halte, ist: ( volle 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,Was nach meinem Verständnis Bash zeigt: (Ich könnte das schrecklich missverstehen. Ich bin hier weit aus meinem Element heraus.)
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.Dieselbe Strace, die auf einer Box ohne diese Probleme durchgeführt wurde (Ubuntu, Bash 4.2.24 (1)), führte zu:
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,Frage
Was zum Teufel ist los und warum ist meine Bash kaputt? :(
Ich vermute, es gibt wahrscheinlich nur eine Option, die standardmäßig etwas Unerwartetes enthält, aber Stunden bei Google haben nichts ergeben.
Jede Hilfe und / oder Hinweise werden sehr geschätzt. Das ist wirklich frustrierend.
Vielen Dank.
exec bashund exec bash -lzeigen das gleiche Verhalten. Ich nehme an, es ist ein kleiner Trost, dass ich damit nicht allein bin. Ich bin jedoch völlig verwirrt darüber, was dies verursachen würde. Das colo installierte eine minimale Installation von einem frisch heruntergeladenen Debian-Image. Ich muss versuchen, lokal zu installieren, um festzustellen, ob es Probleme gibt, und (vorausgesetzt, keine, da dies bei anderen Personen nicht der Fall zu sein scheint) mit dem Vergleich mit dem laufenden System beginnen.
/etc/bash.bashrcAlle /etc/profileund /etc/profile.d-Dateien bleiben bei einer Neuinstallation unverändert. Ich habe die Bash-Quelle ( apt-get source bash) heruntergeladen und spiele mit verschiedenen Argumenten ./configure, um das Problem einzugrenzen, bevor ich mich mit der Quelle befasse.
--disable-readline --enable-minimal-config --disable-job-control, eine Strace ausgeführt, um zu sehen, welche Dateien es sein würde open, alle diese Dateien umbenannt und mich dann erneut angemeldet. Gleicher Fehler. Ich habe Konfigurationsänderungen mit bash selbst ziemlich definitiv ausgeschlossen.
exec bashvon Hand (es ist also keine Login-Shell mehr), verhält es sich dann immer noch schlecht? Wenn nicht, was ist mitexec bash -l(es ist also eine Login-Shell)? Wenn ja, dann stimmt etwas nicht mit Ihren Anmeldeskripten (/etc/profile/etc/profile.d/~/.bash_profile~/.profile), aber ich weiß nicht einmal, was ich Ihnen sagen soll, um danach zu suchen, was der Shell sagen kann, dass sie es nicht tun sollSIGWINCH.