Изменить на 2016 год:
Эти вопросы предшествуют разгрому 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.
В этом конкретном контексте наиболее вероятными причинами записи являются:
- Процесс (обычно на переднем плане), пытающийся записать в PTY на стороне сервера. (Server-> клиент)
- Пользователь пытается записать в PTY на стороне клиента. (Клиент-> сервер)
- Keepalive любого рода. Обычно они не включены по умолчанию ни клиентом, ни сервером, и обычно существует два варианта: уровень приложения и основанный на TCP (т.е.
SO_KEEPALIVE). Keepalive равносильно тому, что сервер или клиент отправляют пакеты на другую сторону нечасто, даже если в противном случае не было бы причины для записи в сокет. Хотя это обычно предназначено для обхода брандмауэров, которые слишком быстро блокируют время ожидания соединения, у него есть дополнительный побочный эффект, когда отправитель замечает, что другая сторона не отвечает так быстро.
Здесь применяются обычные правила для сеансов TCP: если в соединении между клиентом и сервером существует прерывание, но ни одна из сторон не пытается отправить пакет во время проблемы, соединение сохранится при условии, что обе стороны ответят и получат ожидаемый TCP порядковые номера.
Если одна из сторон решила, что сокет мертв, эффекты обычно бывают немедленными: процесс sshd отправит HUPи завершит работу самостоятельно (как описано ранее), или клиент уведомит пользователя об обнаруженной проблеме. Стоит отметить, что только то, что одна сторона думает, что другая мертва, не означает, что другая сторона была уведомлена об этом. Потерянная сторона соединения, как правило, будет оставаться открытой до тех пор, пока она не попытается выполнить запись и тайм-аут или не получит сброс TCP с другой стороны. (если подключение было доступно в то время) Очистка, описанная в этом ответе, происходит только после того, как сервер заметил.
screen, попробуйте reptyr .