Riprendi il comando in esecuzione nella sessione SSH rilasciata

Leggere questa domanda mi ha fatto riflettere. Supponendo che screennon venga utilizzato. Se una sessione SSH su una destinazione Linux viene interrotta, per qualsiasi motivo, e ti riconnetti prima che il server uccida la sessione a causa del timeout, è possibile riprendere il controllo del comando in esecuzione in modo che non venga interrotto a causa della sessione interrotta ?

Il tentativo di connettere i descrittori di file STD * di un nuovo terminale a un vecchio processo in esecuzione richiede solo problemi. Anche se riesci a farlo, il controllo dei lavori del terminale non funzionerà come previsto. Ti verrà lasciato un casino se alla fine esci dal programma acquisito, e cosa succede alla shell che ha sacrificato i suoi descrittori di file per essere consegnata al processo di nuovo background. SSH rimarrà aperto quando quel guscio scompare? Probabilmente no. Quindi dovrai prima reindirizzarlo da qualche altra parte.

Possibile o no, scommetterei che è più desiderabile lasciare che il processo abbandonato venga ucciso "naturalmente". Se stai facendo qualcosa di abbastanza importante da giustificare il tentativo di fare tutti gli hacker richiesti per riprendere il controllo e sei su un collegamento instabile, probabilmente dovresti sapere che in anticipo e usare semplicemente lo schermo (o vnc, o qualunque cosa galleggi il tuo distaccato- barca di controllo). :)

So che questa è una vecchia domanda, ma ho ritenuto importante aggiungere le mie scoperte nel caso in cui qualcun altro si imbattesse in questo, come ho fatto io.

Non ho visto conseguenze insolite nel fare questo sì, ma questo è quello che ho usato e ha funzionato meravigliosamente. A volte quando eseguiamo lunghi processi sul nostro server, a volte disconnettiamo la sessione ssh. Il processo insieme alla sessione tty sembra funzionare ma non possiamo riconnetterci. Ho trovato il programma qui sotto per portare il processo alla sessione appena connessa.

https://github.com/nelhage/reptyr

Ecco maggiori informazioni

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

Generalmente, il modo giusto di gestirlo è prepararsi in anticipo, usando GNU screeno bash nohupo disownmeccanismi. Se si utilizza tcsh, la shell rinnegherà i processi in background quando esce in modo anomalo.

Se non stai utilizzando, screenma sei riuscito a mantenere il processo in esecuzione tramite uno dei metodi rinnegati , potresti essere in grado di falsificare la riconnessione al processo con gdb( fonte ):

[...] con alcuni hack sporchi, non è impossibile riaprire un processo 'stdout / stderr / stdin. [...]

E poi usa gdb per esempio per collegarti al processo, esegui qualche chiamata close (0)
call close (1)
call close (2)
call open ("/ dev / pts / xx", ...)
call dup (0)
call dup (0)
staccare

Ora, dovresti modificare questo processo per la tua situazione. Dubito che sarebbe d'aiuto se non sei riuscito a rinnegare il processo. Se si sta utilizzando bash, vedi questo post su come rendere bash automaticamente rinnegare i processi in background in uscita (in pratica, spegnere huponexit con shopt ). Con un processo in primo piano, devi aver usato nohup .

Probabilmente no. Non posso garantire che sia impossibile ma ne dubito davvero.

Una cosa è la mancanza di uccisione della shell e dei possibili comandi in esecuzione a seguito della chiusura della connessione ssh. Questo non è così difficile, dovresti essere in grado di usare nohup e meccanismi simili come menzionato nell'altra domanda.

Ma poi, supponi che tu abbia iniziato ssh somehost nuhup vim /some/filee la connessione si interrompa. Corri ssh somehostper accedere di nuovo e puoi vedere che il tuo processo vim è ancora in esecuzione. Ma allora, come ti connetti di nuovo a quel processo? I processi interattivi forground hanno un tty di controllo e quello aperto per il tuo processo vim da quando sarebbe iniziato da allora sarebbe stato chiuso. Non sono sicuro che ci sia un modo per "riaprirlo" di nuovo nella tua nuova shell (proprio come se avessi diversi lavori in background in esecuzione in una shell non puoi mettere in primo piano nessuno di quelli in un'altra shell).

Screensono stati esplicitamente scritti per avere questa funzionalità. All'avvio forgia due processi, un processo di gestione dei terminali e un processo client. L'interazione è l'applicazione client <--> terminal manager <--> e quando si scollega o si perde la connessione il processo client termina mentre il gestore terminal continua a vivere. Lo schermo ha un supporto specifico da allegare al processo di gestione del terminale in un secondo momento, e non credo che ciò sia possibile nel caso generale.

retty potrebbe essere in grado di aiutarti, ma le dichiarazioni di non responsabilità sono molto reali e pertinenti :)

Se la sessione viene interrotta, significa che TTL è già scaduto, quindi non c'è più tty per te (come ho capito). Tuttavia, se la connessione di rete viene interrotta, potrebbe non essere necessario interrompere la sessione SSH e si dovrebbe essere in grado di riprendere la connessione e continuare. È quello che stai chiedendo?

In questa domanda c'era un collegamento ad un codice che ruba in modo confuso . Teoricamente dovresti essere in grado di usarlo per riprendere il controllo di un processo nohup.