Niedawno ponownie zainstalowaliśmy nasz serwer z powodu awarii dysku, a teraz mamy problem ze zmianą rozmiaru terminali. Zainstalowaliśmy Debian 6.0.6.
Objawy
Podczas zmiany rozmiaru terminala nie wydaje się, aby aplikacje oparte na ncurses (testowane: ytalk, irssi, screen, tmux, niektóre z przykładowych aplikacji ncurses) zmieniły rozmiar. Ekran zwykle jest pusty. Wymuszenie przerysowania w aplikacji spowoduje przerysowanie przy użyciu starego rozmiaru terminala.
Podczas zmiany rozmiaru okna po znaku zachęty (4.1.5 (1)) zmienne COLUMNS i LINES nigdy nie są aktualizowane.
Diagnostyka
Próbując złapać SIGWINCHA w bash, wydaje się, że nigdy nie jest odbierany. Zostało to przetestowane z:
trap 'touch /home/user/sigwinch' SIGWINCH
trap 'touch /home/user/sigusr1' SIGUSR1
kill -s SIGWINCH $$
kill -s SIGUSR1 $$Które powinny były utworzyć oba pliki w moim katalogu domowym. To tylko stworzyło /home/user/sigusr1.
Próba kill -s SIGWINCH $$nie powoduje aktualizacji zmiennych $ COLUMNS / $ LINES.
Włączenie checkwinsize( shopt -s checkwinsize) spowoduje, że bash zaktualizuje $ COLUMNS / $ LINES po powrocie z dowolnej aplikacji (zgodnie z oczekiwaniami). Prowadzi to do następujących po zmianie rozmiaru terminala z checkwinsizewłączonym:
$ echo $COLUMNS ; ls > /dev/null ; echo $COLUMNS
72
107Zmiana powłoki logowania na coś takiego jak tcsh i próba zmiany rozmiaru terminala działa zgodnie z oczekiwaniami, podobnie jak bash na innych testowanych przeze mnie urządzeniach.
Próbowałem usunąć plik .bashrc i nic nie dało. Ten problem występuje u kilku innych użytkowników z różnymi konfiguracjami bash zarówno w PuTTY, jak i pewnego rodzaju terminalu typu rxvt z Linux-a.
strace
Uruchomiłem strace na bashu i próbowałem zmienić rozmiar terminala, nic nie przeszło (pozostało zablokowane podczas readpołączenia natychmiast po wydrukowaniu monitu).
Nacisnąłem return na pustej linii i bash zrobił całą masę rzeczy. Wynik, który moim zdaniem jest istotny, to: ( pełna wersja )
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,Który pokazuje bash, według mojego zrozumienia: (Mógłbym być strasznie niezrozumiały. Jestem tutaj daleko od mojego żywiołu.)
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.Ta sama strace wykonana na pudełku bez tych problemów (Ubuntu, bash 4.2.24 (1)) spowodowała:
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,Pytanie
Co się do cholery dzieje i dlaczego moja łamana walka jest zepsuta? :(
Domyślam się, że prawdopodobnie jest gdzieś tylko opcja, która domyślnie spowodowała coś nieoczekiwanego, ale godziny w Google nic nie pokazały.
Każda pomoc i / lub wskazówki są bardzo mile widziane. To jest naprawdę frustrujące.
Dziękuję Ci.
exec bashi exec bash -lwykazują takie same zachowanie. Przypuszczam, że to mała pociecha, że nie jestem w tym sam. Jestem jednak całkowicie zdezorientowany, co by to spowodowało. Colo zainstalowało minimalną instalację ze świeżo pobranego obrazu Debiana. Będę musiał spróbować zainstalować lokalnie i sprawdzić, czy są jakieś problemy i (zakładając, że nie występują, ponieważ wydaje się, że tak się nie dzieje u innych osób), zacznij porównywać z działającym systemem.
/etc/bash.bashrca wszystkie pliki /etc/profilei /etc/profile.dpozostają niezmienione od czystej instalacji. Pobrałem bash source ( apt-get source bash) i gram z różnymi argumentami, ./configureaby spróbować zawęzić problem przed kopaniem do źródła.
--disable-readline --enable-minimal-config --disable-job-control, uruchomiłem śledzenie, by zobaczyć, które to pliki open, zmieniłem nazwy wszystkich plików, a następnie zalogowałem się ponownie. Ten sam problem. Zupełnie zdecydowanie wykluczyłem wszelkie zmiany konfiguracji samego basha.
exec bashręcznie (więc nie jest to już powłoka logowania), to nadal źle się zachowuje? Jeśli nie, to co zexec bash -l(więc jest to powłoka logowania)? Jeśli tak, to coś jest nie tak z twoimi skryptami logowania (/etc/profile/etc/profile.d/~/.bash_profile~/.profile), ale nawet nie wiem, co powiedzieć, żebyś szukał, co może powiedzieć powłoce, że nieSIGWINCH.