Если я выполнял команду до того, как соединение SSH было разорвано, продолжит ли выполнение команда?
В большинстве случаев нет. Процессам будет отправлено SIGHUP при потере терминала. Вы можете префикс команды с "nohup", чтобы игнорировать сигнал. Видеть:
Я добавлю в ветку еще одно полезное предложение, которое я узнал несколько минут назад:
Если вы уже запустили процесс, который займет много времени (в моем случае восстановление tar), и забыли включить nohup перед ним, вы все равно можете предотвратить его завершение при выходе из системы.
Вот шаги:
Как говорит Уорнер выше, дочерний элемент демона 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 с другой стороны. . (если соединение было доступно в то время)
Ответ Warner точен. Как вариант, вы также можете выполнить команду в фоновом режиме, добавив амперсанд (&) в конец команды.