В чем разница между (cp f1.txt f2.txt) и (меньше f1.txt> f2.txt) [дубликат]
Я нашел это в списке проблем на github, и я думаю, что это действительно ответ на ваш вопрос.
На самом деле это не проблема SSH, это скорее тонкое поведение в неинтерактивных / интерактивных режимах BASH и распространение сигнала на группы процессов.
Следующее основано на https: // stackoverflow.com / questions / 14679178 / why-does-ssh-wait-for-my-subshells-without-t-and-kill-them-with-t / 14866774 # 14866774 и http : //www.itp.uzh.ch/~dpotter/howto/daemonize , при этом некоторые предположения не полностью подтверждены, но тесты того, как это работает, похоже, подтверждают.
pty / tty = false
Запущенная оболочка bash подключается к stdout / stderr / stdin запущенного процесса и продолжает работать до тех пор, пока ничего не будет прикреплено к сокетам и это дети вышли. Хороший процесс демона гарантирует, что он не дожидается завершения дочернего процесса, разветвляет дочерний процесс и затем завершает работу. В этом режиме SSH не отправляет SIGHUP дочернему процессу . Я считаю, что это будет работать правильно для большинства сценариев , выполняющих процесс, который обрабатывает саму деамонизацию и не требует фоновой обработки. Если в сценариях инициализации используется '&' для фоновой обработки процесса , то, вероятно, основная проблема будет заключаться в том, пытается ли фоновый процесс когда-либо читать из стандартного ввода, поскольку это вызовет SIGHUP, если сеанс был прерван.
pty / tty = true *
Если сценарий инициализации запускает процесс, родительская оболочка BASH вернет код выхода для SSH-соединения, которое через изменится для немедленного выхода, поскольку он не ждет завершения дочернего процесса и не блокируется на stdout / stderr / stdin. Это вызовет отправку SIGHUP родительской группе процессов оболочки bash, которая, поскольку управление заданиями отключено в неинтерактивном режиме в bash, будет включать дочерние процессы только что запущенный.Если процесс-демон явно запускает новый сеанс процесса при разветвлении или в разветвленном процессе , тогда он или его дочерние элементы не получат SIGHUP от выхода родительского процесса BASH. Обратите внимание, что это отличается от приостановленных заданий , которые будут видеть SIGTERM. Я подозреваю, что проблемы, связанные с этой только работой, иногда связаны с небольшим состоянием гонки. Если вы посмотрите на стандартный подход к деамонизации - http://www.itp.uzh.ch/~dpotter/howto/daemonize, вы увидите, что в коде новый сеанс создается разветвленным процессом, который не может быть {{1} } выполняется до выхода из родительского объекта, что приводит к случайному успешному / неудачному поведению, упомянутому выше. Оператор сна дает достаточно времени для разветвленного процесса, чтобы создать новый сеанс, поэтому в некоторых случаях он работает.
pty / tty = true и управление заданиями явно включено в bash
SSH не будет подключаться к stdout / stderr / stdin оболочки bash или каким-либо запущенным дочерним процессам, что будет означать это завершится, как только родительская оболочка bash завершит выполнение запрошенных команд. В этом случае при явно включенном управлении заданиями все процессы , запущенные оболочкой bash с ' & 'в фоновом режиме они будут немедленно помещены в отдельный сеанс и не будут получать сигнал SIGHUP , когда родительский процесс для сеанса BASH завершается (соединение SSH в этом кейс).
Что нужно исправить
Я думаю, что решения просто нужно явно упомянуть в документации по операциям run / sudo как особый случай при работе с фоновыми процессами / службами. Обычно либо используйте pty = false, либо , где это невозможно, явно включите управление заданием в качестве первой команды , и поведение будет правильным.