Mam kilka długich sesji ekranowych GNU. Piszę do skrzynki, na której są uruchomione, i biegam, screen -d -r foo
aby je odłączyć, jeśli są połączone gdziekolwiek indziej, a następnie dołączyć je w moim bieżącym oknie.
W 99% przypadków działa to dobrze, ale czasami dostaję to:
$ screen -d -r foo
[2430.foo detached.]
... i nic się nie dzieje; W ogóle nie mogę wrócić do muszli. Próbowanie w innym oknie robi to samo, jedyne, co mogę zrobić, to zniszczyć tę sesję ekranu (tracąc wszystkie uruchomione w niej programy) i odtworzyć ją
Dlaczego to się dzieje? Jak mogę tego uniknąć lub pomyślnie połączyć się ponownie, kiedy to się stanie?
Edycja : Mój .screenrc
:
startup_message off
defwritelock off
bind q quit
caption always '%{gk} (%n) %t %{y}%d %M %Y :: %c:%s %{b}%W%{d}'
screen -t ZSH
autodetach on
shelltitle ZSH
defutf8 on
Edycja : koniec strace
dziennika podczas próby dołączenia:
readlink("/proc/self/fd/0", "/dev/pts/14", 4095) = 11
stat64("/dev/pts/14", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 14), ...}) = 0
stat64("/dev/pts/14", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 14), ...}) = 0
geteuid32() = 1000
getegid32() = 1000
open("/dev/pts/14", O_RDWR|O_NONBLOCK) = 3
geteuid32() = 1000
getegid32() = 1000
close(3) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
umask(0) = 022
lstat64("/var/run/screen", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
access("/var/run/screen/S-mrozekma", F_OK) = 0
stat64("/var/run/screen/S-mrozekma", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
umask(022) = 0
uname({sys="Linux", node="etudes-2", ...}) = 0
rt_sigaction(SIGHUP, {0x806e520, [], 0}, {SIG_DFL, [], 0}, 8) = 0
geteuid32() = 1000
getegid32() = 1000
open("/var/run/screen/S-mrozekma", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 6 entries */, 32768) = 124
stat64("/var/run/screen/S-mrozekma/2386.chat", {st_mode=S_IFIFO|0700, st_size=0, ...}) = 0
geteuid32() = 1000
getegid32() = 1000
open("/var/run/screen/S-mrozekma/2386.chat", O_WRONLY|O_NONBLOCK) = 4
geteuid32() = 1000
getegid32() = 1000
fcntl64(4, F_SETFL, O_RDONLY) = 0
geteuid32() = 1000
getegid32() = 1000
getdents(3, /* 0 entries */, 32768) = 0
close(3) = 0
geteuid32() = 1000
getegid32() = 1000
setuid32(1000) = 0
setgid32(1000) = 0
stat64("/var/run/screen/S-mrozekma/2386.chat", {st_mode=S_IFIFO|0700, st_size=0, ...}) = 0
getpid() = 30081
write(4, "\0gsm\4\0\0\0/dev/pts/14\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 12336
ssh
gnu-screen
Michał Mrożek
źródło
źródło
strace screen -d -r foo
(być może konieczne będzie wykonanie nie ustawionej kopii [ug] idscreen
pliku wykonywalnego) istrace -p$(pidof SCREEN)
mniej więcej w czasie nieudanego ponownego połączenia.strace
dziennik.strace
Proces głównego ekranu pokazuje podobny blok wwrite()
rozmowiescreen
próbujesz zapisać połączenie, które już nie istnieje?SCREEN
) jest nadal aktywny? Co on robi (strace
)?Odpowiedzi:
Nie jestem pewien, czy miałem ten sam problem co ty, ale czasami mam podobne zachowanie ekranu za każdym razem, gdy moja sieć została przypadkowo odłączona.
Po chwili (około 10-15 minut) ekran jest ponownie dostępny do ponownego połączenia. Po kilku dochodzeniach znalazłem małą notatkę na stronie podręcznika:
Może to komuś pomoże, bo to jedyna strona o zawieszeniu ekranu po tym, jak dała mi go niezadowolenie.
źródło
nonblock 5
jakiś czas temu i po prostu znów natknąłem się na problem, a po 5 sekundach nagle przyłączyłem się normalnieSesja ekranowa prawdopodobnie została zawieszona w oczekiwaniu na pseudo-terminal powłoki, którą ostatnio podłączono do ekranu. Czasami utracone połączenie pozostawia tę powłokę i ekran musi przekroczyć limit czasu, aby się od niego odłączyć.
Jeśli uruchomisz
ls -l /proc/<screen_pid>/fd/<descriptor_of_hung_write>
, powinieneś zobaczyć, że jest to punkt dla poprzedniej sesji powłoki.Po zabiciu sesji bash / shell, z którą się przyłączyłeś, będziesz mógł ponownie dołączyć.
W takim przypadku proces zabijania 23214 spowoduje zwolnienie sesji ekranowej i będzie można ponownie dołączyć.
źródło
Czy ekran został zaktualizowany od czasu rozpoczęcia tych sesji ekranowych?
Nie pamiętam dokładnych szczegółów, ale pamiętam, że mniej więcej miesiąc lub trzy lata temu
apt-get dist-upgrade
(do Debiana Sid) zaktualizowałem ekran w moim systemie, a postinst ostrzegł mnie przed niekompatybilnym uaktualnieniem. Kopia starego ekranu została zachowana (gdzieś w / tmp IIRC), aby umożliwić ponowne dołączanie do starych sesji, ale zalecane było zabicie ich i ponowne uruchomienie.Zgłaszane symptomy brzmią podobnie do tego, co widziałem, gdy przypadkowo próbowałem ponownie połączyć się ze starą sesją ekranową z nowym / usr / bin / screen.
Możliwe, że to z dpkg.log w czerwcu:
2012-06-14 08:11:51 upgrade screen:amd64 4.0.3-14 4.1.0~20120320gitdb59704-2
źródło