Итак, скажем, я отключаюсь от SSH-сеанса после того, как начал rsync или cp или любая другая команда, которая может работать долго. Эта команда продолжает работать, пока не будет завершена после того, как я отключусь, или ее просто убьют?
Всегда удивлялся этому.
Эти вопросы и ответы предшествуют Systemd v230 фиаско. Начиная с systemd v230, новым значением по умолчанию является уничтожение всех дочерних элементов завершающегося сеанса входа в систему, независимо от того, какие исторически действующие меры предосторожности были приняты для предотвращения этого. Поведение можно изменить, установив KillUserProcesses=no в /etc/systemd/logind.conf, или обойтись с использованием специфичных для systemd механизмов для запуска демона в пользовательском пространстве. Эти механизмы выходят за рамки этого вопроса.
Текст ниже описывает, как вещи традиционно работали в пространстве проектирования UNIX дольше, чем существовала Linux.
Их убьют, но не обязательно сразу. Это зависит от того, сколько времени потребуется демону SSH, чтобы решить, что ваше соединение разорвано. Далее следует более подробное объяснение, которое поможет вам понять, как это на самом деле работает.
Когда вы вошли в систему, демон SSH выделил вам псевдотерминал и подключил его к оболочке входа, настроенной вашим пользователем. Это называется управляющим терминалом. Каждая программа, которую вы обычно запускаете в этот момент, независимо от того, сколько слоев оболочки глубоко, в конечном итоге прослеживает свою родословную до этой оболочки. Вы можете наблюдать это с помощью pstree команда.
Когда процесс демона SSH, связанный с вашим соединением, решает, что ваше соединение не работает, он отправляет сигнал зависания (SIGHUP) в оболочку входа. Это уведомляет оболочку о том, что вы исчезли, и что она должна начать очистку после себя. То, что происходит в этот момент, зависит от оболочки (найдите на странице документации по запросу "HUP"), но по большей части он начнет отправлять SIGHUP для выполнения связанных с ним заданий до завершения. Каждый из этих процессов, в свою очередь, будет делать все, что он настроен, по получении этого сигнала. Обычно это означает прекращение. Если у этих рабочих мест есть собственная работа, сигнал также часто передается.
Процессы, которые выживают после зависания управляющего терминала, - это те, которые либо отказались от терминала (процессы-демоны, которые вы запустили внутри него), либо те, которые были вызваны с префиксом nohup команда. (т.е. «не кладите трубку») Демоны по-разному интерпретируют сигнал HUP; поскольку у них нет управляющего терминала и они не получают автоматически сигнал HUP, он вместо этого используется как ручной запрос от администратора для перезагрузки конфигурации. По иронии судьбы это означает, что большинство администраторов не узнают об использовании этого сигнала "зависания" для недемонов намного, намного позже. Вот почему вы это читаете!
Терминальные мультиплексоры - это распространенный способ сохранить целостность среды оболочки между отключениями. Они позволяют вам отключиться от процессов оболочки таким образом, чтобы вы могли повторно подключиться к ним позже, независимо от того, было ли это отключение случайным или преднамеренным. tmux и screen самые популярные; синтаксис для их использования выходит за рамки вашего вопроса, но их стоит изучить.
Меня попросили уточнить, сколько времени потребуется демону SSH, чтобы решить, что ваше соединение не работает. Это поведение, характерное для каждой реализации демона SSH, но вы можете рассчитывать, что все они завершатся, когда одна из сторон сбросит TCP-соединение. Это произойдет быстро, если сервер попытается записать в сокет, а пакеты TCP не будут подтверждены, или медленно, если ничего не попытается записать в PTY.
В данном конкретном контексте наиболее вероятными факторами, вызывающими запись, являются:
SO_KEEPALIVE). Keepalive означает, что сервер или клиент нечасто отправляют пакеты другой стороне, даже если в противном случае ничто не имело бы причин для записи в сокет. Хотя это обычно предназначено для обхода брандмауэров, которые слишком быстро прерывают соединения, у него есть дополнительный побочный эффект, заставляющий отправителя замечать, когда другая сторона не отвечает намного быстрее.Здесь применяются обычные правила для сеансов TCP: если соединение между клиентом и сервером прервано, но ни одна из сторон не пытается отправить пакет во время проблемы, соединение будет сохранено при условии, что обе стороны после этого ответят и получат ожидаемый TCP порядковые номера.
Если одна сторона решила, что сокет мертв, эффекты обычно проявляются немедленно: процесс sshd отправит HUP и самозавершиться (как описано ранее), или клиент уведомит пользователя об обнаруженной проблеме. Стоит отметить, что то, что одна сторона думает, что другая мертва, не означает, что другая была уведомлена об этом. Осиротевшая сторона соединения обычно остается открытой до тех пор, пока либо она не попытается выполнить запись и не истечет время ожидания, либо не получит сброс TCP с другой стороны. (если подключение было доступно в то время) Очистка, описанная в этом ответе, происходит только после того, как сервер заметил.
Как уже упоминали другие, после отключения от ssh все, что в нем работает, исчезает.
Так как @ Майкл Хэмптон и другие упомянули, что вы можете использовать такие инструменты, как tmux или screen для отключения / повторного подключения к терминалам без потери их содержимого (то есть дочерних процессов).
Кроме того, вы можете поместить процесс в фоновый режим, используя амперсанд & а затем используйте команду disown чтобы отделить их от текущей оболочки.
# start a command
% sleep 5000 &
[1] 3820
# check it
% jobs
[1]+ Running sleep 5000 &
# disown everything
% disown -a
# check it again (gone from shell)
% jobs
%
# but it's still running on the system
% ps -eaf|grep "[s]leep"
saml 3820 23791 0 00:16 pts/1 00:00:00 sleep 5000
%
Нет, программы все еще прикреплены к терминалу и не помещены в фон с чем-то вроде nohup, будет убит.
Вот почему существуют решения для виртуальных терминалов, такие как tmux и старший screen которые создают сеансы, которые продолжают работать, даже если вы отключены, и к которым вы можете подключиться позже.