Сеанс SSH прекращается - команда продолжает выполняться?

Я добавлю еще одно замечательное предложение в ветку, которое я только что узнал несколько минут назад:

Если вы уже запустили процесс, который займет много времени (восстановление tar в моем случае), и забыли включить перед ним nohup, вы все равно можете предотвратить его завершение при выходе из системы.

Вот шаги:

1. Нажмите Ctrl + Z - это приостановит работу
2. Введите disown -h% x, где x - номер работы, которую вы получите после приостановки работы
3. Выполните bg, чтобы поместить задание в фоновый режим.
4. Выйдите из оболочки и продолжайте свою жизнь:).

Как говорит Warner выше, дочерний элемент демона ssh (это оболочка входа в систему и его дочерние элементы) получит SIGHUP, но они не получат их мгновенно. Будет задержка, иногда за несколько минут до того, как демон ssh на стороне сервера откажется от вашего соединения. В течение этого времени процесс будет продолжаться.

Как также сказал Уорнер, процесс может игнорировать SIGHUP, в этом случае, он будет продолжать работать до тех пор, пока не будет запрашивать ввод, а затем найти STDIN закрыл

Не совсем, хотя и не зная, какую оболочку или даже какую ОС вы используете, сложно сказать. Например, если вы запускаете его под экраном, я думаю, что нужно отключить его и продолжить работу. Может быть, некоторые другие оболочки имеют это в качестве настраиваемой опции.

Я нашел лучший ответ по ссылке ниже

Отключение от сеанса SSH убивает ваши программы?

Изменить на 2016 год:

Эти вопросы предшествуют разгрому systemd v230. Начиная с systemd v230, новым значением по умолчанию является уничтожение всех дочерних элементов завершающего сеанса входа в систему, независимо от того, какие исторически действительные меры предосторожности были приняты для предотвращения этого. Поведение можно изменить, установив KillUserProcesses = no в /etc/systemd/logind.conf, или обойти, используя специфичные для systemd механизмы для запуска демона в пользовательском пространстве. Эти механизмы выходят за рамки этого вопроса.

Приведенный ниже текст описывает, как вещи обычно работали в пространстве разработки UNIX дольше, чем существовал Linux.

Их убьют, но не обязательно сразу. Это зависит от того, сколько времени демон SSH решит, что ваше соединение разорвано. Далее следует более длинное объяснение, которое поможет вам понять, как это на самом деле работает.

Когда вы вошли в систему, демон SSH выделил для вас псевдотерминал и подключил его к настроенной оболочке входа вашего пользователя. Это называется управляющим терминалом. Каждая программа, которую вы обычно запускаете в этот момент, независимо от того, сколько слоев раковин в глубине, в конечном итоге будет "прослеживать свое происхождение" обратно в эту оболочку. Вы можете наблюдать это с помощью команды pstree.

Когда процесс демона SSH, связанный с вашим соединением, решает, что ваше соединение разорвано, он отправляет сигнал зависания (SIGHUP) в оболочку входа. Это уведомляет оболочку о том, что вы исчезли, и что она должна начать очистку после себя; то, что происходит в этот момент, зависит от оболочки (поищите на странице документации "HUP"), но по большей части он начнет посылать SIGHUP выполняющимся заданиям, связанным с ним, прежде чем завершится. Каждый из этих процессов, в свою очередь, будет делать все, что настроено для получения этого сигнала. Обычно это означает прекращение. Если на этих работах есть свои собственные работы, сигнал часто будет передаваться вместе.

Процессы, которые переживают зависание управляющего терминала, - это те, которые либо не связывают себя с наличием терминала (процессы-демоны, которые вы запустили внутри него), либо те, которые были вызваны с помощью префиксной команды nohup. (т.е. "не вешай на это")

Терминальные мультиплексоры являются распространенным способом сохранения целостности вашей оболочки между отключениями. Они позволяют вам отсоединиться от процессов оболочки таким образом, чтобы вы могли подключиться к ним позже, независимо от того, было ли это отключение случайным или преднамеренным. tmux и screen - наиболее популярные из них; Синтаксис их использования выходит за рамки вашего вопроса, но их стоит рассмотреть.

Меня попросили уточнить, "сколько времени демону SSH требуется, чтобы решить, что ваше соединение разорвано". Это поведение, характерное для каждой реализации демона SSH, но вы можете рассчитывать на то, что все они прекратят работу, когда любая из сторон сбрасывает TCP-соединение. Это произойдет быстро, если любая из сторон попытается выполнить запись в сокет, а пакеты TCP не будут подтверждены, или медленно, если ни одна из сторон не попытается выполнить запись в PTY.

В этом конкретном контексте наиболее вероятными причинами записи являются:

• Процесс (обычно на переднем плане), пытающийся записать в PTY на стороне сервера (сервер-> клиент). Пользователь пытается записать в PTY на стороне клиента (клиент-> сервер).

• Keepalive любого рода. Обычно они не включены по умолчанию ни клиентом, ни сервером, и обычно есть два варианта: уровень приложения и основанный на TCP (т. Е. SO_KEEPALIVE). Keepalive равносильно тому, что сервер или клиент отправляют пакеты на другую сторону нечасто, даже если в противном случае не было бы причины для записи в сокет. Хотя это обычно предназначено для обхода брандмауэров, которые слишком быстро блокируют время ожидания соединения, у него есть дополнительный побочный эффект, когда отправитель замечает, что другая сторона не отвечает так быстро.

Здесь применяются обычные правила для сеансов TCP: если в соединении между клиентом и сервером существует прерывание, но ни одна из сторон не пытается отправить пакет во время проблемы, соединение сохранится при условии, что обе стороны ответят и получат ожидаемый TCP порядковые номера.

Если одна из сторон решила, что сокет мертв, эффекты обычно бывают немедленными: процесс sshd отправит HUP и завершит свою работу (как описано ранее), или клиент уведомит пользователя о обнаруженной проблеме. Стоит отметить, что то, что одна сторона думает, что другая мертва, не означает, что другая сторона была уведомлена об этом, и, как правило, остается открытой до тех пор, пока она не попытается выполнить запись в соединение или не получит сброс TCP с другой стороны., (если связь была доступна в то время)

Ответ Уорнера на месте. Кроме того, вы также можете выполнить команду в фоновом режиме, добавив амперсанд (&) в конец команды.