Чтение этот вопрос заставил меня задуматься. Предполагая screen не используется. Если сеанс SSH на цели Linux по какой-либо причине прерван, и вы повторно подключаетесь до того, как сервер завершит сеанс из-за тайм-аута, возможно ли восстановить контроль над выполняющейся командой, чтобы она не была прервана из-за прерванного сеанса ?
Попытка подключить дескрипторы файлов STD * нового терминала к старому запущенному процессу просто вызывает проблемы. Даже если вам это удастся, управление заданиями терминала не будет работать должным образом. У вас останется беспорядок, если вы в конечном итоге выйдете из принятой программы, и что произойдет с оболочкой, которая пожертвовала своими файловыми дескрипторами для передачи новому фоновому процессу. Будет ли ssh оставаться открытым, когда эта оболочка исчезнет? Возможно нет. Поэтому сначала вам нужно перенаправить его в другое место.
Возможно это или нет, но я бы поспорил, что более желательно просто позволить заброшенному процессу убить «естественным образом». Если вы делаете что-то достаточно важное, чтобы оправдать попытку выполнить все хакерские действия, необходимые для возобновления управления и вы находитесь на нестабильной ссылке, вам, вероятно, следует знать об этом заранее и просто использовать screen (или vnc, или что-то еще, что плавает на вашей лодке с автономным управлением). :)
Я знаю, что это старый вопрос, но я счел важным добавить свои выводы на тот случай, если кто-то еще столкнется с этим, как я.
Я не видел никаких необычных последствий для этого, да, но это то, что я использовал, и это сработало потрясающе. Иногда, когда мы запускаем длинные процессы на нашем сервере, он иногда отключает сеанс ssh. Кажется, что процесс вместе с tty-сеансом продолжает работать, но мы не можем повторно подключиться к нему. Я нашел программу ниже, чтобы перенести процесс на новый подключенный сеанс.
https://github.com/nelhage/reptyr
Вот больше информации
Как правило, правильный способ справиться с этим - подготовиться к этому заранее, используя GNU screen или баш nohup или disown механизмы. Если вы используете tcsh, оболочка отключит фоновые задания при аварийном выходе.
Если вы не используете screen но удалось сохранить работу вашего процесса с помощью одного из отречься методы, вы можете имитировать повторное подключение к процессу с помощью gdb (источник):
[...] с некоторыми грязными хаками невозможно повторно открыть процесс 'stdout / stderr / stdin. [...]
А затем используйте, например, gdb для подключения к процессу, выполните некоторый вызов close (0)
позвонить закрыть (1)
позвонить закрыть (2)
вызовите open ("/ dev / pts / xx", ...)
вызов дубликата (0)
вызов дубликата (0)
отделить
Теперь вам нужно настроить этот процесс для вашей ситуации. Я сомневаюсь, что это поможет, если вам не удалось отречься процесс. Если вы используете bash, посмотреть этот пост о создании трепать автоматически отречься фоновые процессы при выходе (в основном выключить huponexit с участием купил). В процессе переднего плана вам необходимо использовать нету.
Возможно нет. Я не могу гарантировать, что это невозможно, но очень в этом сомневаюсь.
Одна вещь - это отсутствие уничтожения оболочки и возможных команд, выполняемых как следствие разрыва соединения ssh. Это не так уж сложно, вы должны иметь возможность использовать nohup и подобные механизмы, упомянутые в другом вопросе.
Но тогда предположим, что вы начали ssh somehost nuhup vim /some/file и соединение умирает. Ты бежишь ssh somehost чтобы снова войти в систему и увидеть, что ваш процесс vim все еще запущен. Но как вы снова подключитесь к этому процессу? Интерактивные фоновые процессы имеют управляющую tty и тот, который был открыт для вашего процесса vim при его запуске, с тех пор был закрыт. Я не уверен, есть ли способ снова «открыть» его в вашей новой оболочке (точно так же, как если бы у вас было несколько фоновых заданий, запущенных в одной оболочке, вы не можете поставить на передний план ни одно из них в другой оболочке).
Screen были явно написаны для использования этой функции. При запуске он разделяет два процесса: процесс управления терминалом и клиентский процесс. Взаимодействие - это клиент <--> диспетчер терминалов <--> приложение, и когда вы отсоединяете или теряете соединение, клиентский процесс умирает, а диспетчер терминалов продолжает работать. Screen имеет некоторую конкретную поддержку, которую можно позже снова подключить к процессу управления терминалом, и я не думаю, что это возможно в общем случае.
Retty может помочь вам, но заявления об отказе от ответственности вполне реальны и актуальны :)
Если сессия выпадает, это означает, что срок действия TTL уже истек, поэтому для вас больше нет tty (насколько я понимаю). Но если ваше сетевое соединение прервано, ваш сеанс SSH может не прерываться, и вы сможете возобновить свое соединение и продолжить. Вы об этом спрашиваете?
Была ссылка на какой-то хакерский код кражи tty в этот вопрос. Теоретически вы сможете использовать это, чтобы восстановить контроль над процессом nohup.