Wznów polecenie uruchomione w upuszczonej sesji SSH

Czytanie tego pytania doprowadziło mnie do zastanowienia . Zakładając, że screennie jest używany. Jeśli z jakiegoś powodu zostanie przerwana sesja SSH w systemie Linux, a połączenie zostanie nawiązane ponownie, zanim serwer zakończy sesję z powodu przekroczenia limitu czasu, czy można odzyskać kontrolę nad uruchomionym poleceniem, aby nie zostało przerwane z powodu przerwanej sesji ?

Próba połączenia aktualnych deskryptorów plików STD * nowego terminala ze starym działającym procesem wymaga jedynie kłopotów. Nawet jeśli uda ci się to zrobić, kontrola zadań terminala nie będzie działać zgodnie z oczekiwaniami. Będziesz miał bałagan, jeśli w końcu wyjdziesz z przejętego programu, i co stanie się z powłoką, która poświęciła deskryptory plików, aby zostały przekazane nowemu procesowi w tle. Czy ssh pozostanie otwarte, gdy ta skorupa zniknie? Prawdopodobnie nie. Musisz najpierw przekierować go gdzie indziej.

Możliwe czy nie, postawiłbym na to, że bardziej pożądane jest, aby pozwolić, by porzucony proces został zabity „naturalnie”. Jeśli robisz coś na tyle ważnego, aby uzasadnić próbę przeprowadzenia hakera wymaganego do wznowienia kontroli i masz niestabilny link, powinieneś prawdopodobnie wiedzieć o tym wcześniej i po prostu użyć screena (lub vnc, lub cokolwiek, co unosi się z dala) łódź kontrolna). :)

Wiem, że to stare pytanie, ale czułem, że ważne jest, aby dodać moje ustalenia na wypadek, gdyby ktoś inny zetknął się z tym tak jak ja.

Tak, nie widziałem żadnych niezwykłych konsekwencji, ale tego właśnie użyłem i zadziałało to niesamowicie. Czasami, gdy uruchamiamy długie procesy na naszym serwerze, czasami przerywa sesję ssh. Proces wraz z sesją tty wydaje się być kontynuowany, ale nie możemy się z nim ponownie połączyć. Znalazłem program poniżej, aby przeciągnąć proces do nowo podłączonej sesji.

https://github.com/nelhage/reptyr

Oto więcej informacji

https://blog.nelhage.com/2011/02/changing-ctty/

Ogólnie rzecz biorąc, właściwym sposobem na poradzenie sobie z tym jest przygotowanie się na to z wyprzedzeniem, przy użyciu GNU, screenbasha nohuplub disownmechanizmów. Jeśli używasz tcsh, powłoka odrzuci zadania w tle, gdy wyjdzie nienormalnie.

Jeśli nie używasz, screenale udało Ci się utrzymać proces przy użyciu jednej z metod disown , możesz być w stanie sfałszować ponowne połączenie z procesem za pomocą gdb( source ):

[...] przy niektórych brudnych włamaniach ponowne otwarcie procesu „stdout / stderr / stdin” nie jest niemożliwe. [...]

A następnie użyj na przykład gdb, aby dołączyć do procesu, wykonaj kilka połączeń close (0)
call close (1)
call close (2)
call open ("/ dev / pts / xx", ...)
call dup (0)
zadzwoń dup (0)
odłącz

Teraz musisz dostosować ten proces do swojej sytuacji. Wątpię, by to pomogło, gdybyś nie zdementował procesu. Jeśli używasz bash, zobacz ten post o tym, jak bash automatycznie wyrzuca procesy w tle przy wyjściu (w zasadzie wyłącz huponexit w shopt ). W przypadku procesu pierwszoplanowego musisz użyć nohup .

Prawdopodobnie nie. Nie mogę zagwarantować, że jest to niemożliwe, ale naprawdę w to wątpię.

Jedną z rzeczy jest brak zabijania powłoki i możliwe polecenia uruchamiane w wyniku zakończenia połączenia ssh. Nie jest to takie trudne, powinieneś być w stanie używać nohup i podobnych mechanizmów, jak wspomniano w drugim pytaniu.

Ale załóżmy, że zacząłeś ssh somehost nuhup vim /some/filei połączenie umiera. Uruchomisz, ssh somehostaby zalogować się ponownie i zobaczysz, że proces vim nadal działa. Ale jak ponownie połączyć się z tym procesem? Interaktywne procesy naziemne mają kontrolny tty, a ten, który został otwarty dla twojego procesu vim, gdy się uruchomił, od tego czasu byłby zamknięty. Nie jestem pewien, czy istnieje jakikolwiek sposób na „ponowne otwarcie” go w nowej powłoce (tak jak jeśli masz kilka zadań działających w tle w jednej powłoce, nie możesz na pierwszym planie żadnego z nich w innej powłoce).

Screenzostały wyraźnie napisane, aby mieć tę funkcjonalność. Podczas uruchamiania wyświetla dwa procesy: proces zarządzania terminalem i proces klienta. Interakcja to aplikacja kliencka <--> menedżer terminali <-->, a po rozłączeniu lub utracie połączenia proces klienta umiera, podczas gdy menedżer terminali nadal działa. Screen ma pewne szczególne wsparcie, które może później dołączyć do procesu zarządzania terminalami, i nie sądzę, aby było to możliwe w ogólnym przypadku.

retty może ci pomóc, ale zastrzeżenia są bardzo prawdziwe i trafne :)

Jeśli sesja zostanie przerwana, oznacza to, że TTL już wygasło, więc nie ma już dla ciebie tty (jak rozumiem). Ale jeśli połączenie sieciowe zostanie przerwane, sesja SSH może nie wymagać zerwania i powinieneś być w stanie wznowić połączenie i kontynuować. Czy o to pytasz?

W tym pytaniu był link do jakiegoś złośliwego kodu kradzieży tty . Teoretycznie powinieneś być w stanie wykorzystać to, aby odzyskać kontrolę nad procesem nohup.