Почему мой фоновый процесс Python заканчивается, когда сеанс SSH завершается?

У меня есть скрипт bash, который запускает скрипт python3 (давайте назовем его startup.sh) с ключевой строкой:

nohup python3 -u <script> &

Когда я sshвызываю этот скрипт напрямую, скрипт python продолжает работать в фоновом режиме после выхода. Тем не менее, когда я запускаю это:

ssh -i <keyfile> -o StrictHostKeyChecking=no <user>@<hostname> "./startup.sh"

Процесс заканчивается, как только sshон завершится, и закрывает сеанс.

Какая разница между двумя?

РЕДАКТИРОВАТЬ: скрипт Python запускает веб-сервис через бутылку.

РЕДАКТИРОВАТЬ 2: Я также попытался создать сценарий инициализации, который вызывает startup.shи работает ssh -i <keyfile> -o StrictHostKeyChecking=no <user>@<hostname> "sudo service start <servicename>", но получил то же самое поведение.

EDIT3: Может быть, это что-то еще в сценарии. Вот основная часть скрипта:

chmod 700 ${key_loc}

echo "INFO: Syncing files."
rsync -azP -e "ssh -i ${key_loc} -o StrictHostKeyChecking=no" ${source_client_loc} ${remote_user}@${remote_hostname}:${destination_client_loc}

echo "INFO: Running startup script."
ssh -i ${key_loc} -o StrictHostKeyChecking=no ${remote_user}@${remote_hostname} "cd ${destination_client_loc}; chmod u+x ${ctl_script}; ./${ctl_script} restart"

EDIT4: когда я запускаю последнюю строку со сном в конце:

ssh -i ${key_loc} -o StrictHostKeyChecking=no ${remote_user}@${remote_hostname} "cd ${destination_client_loc}; chmod u+x ${ctl_script}; ./${ctl_script} restart; sleep 1"

echo "Finished"

Он никогда не достигает echo "Finished", и я вижу сообщение сервера Bottle, которого я никогда раньше не видел:

Bottle vx.x.x server starting up (using WSGIRefServer())...
Listening on <URL>
Hit Ctrl-C to quit.

Я вижу «Закончено», если я вручную запускаю SSH и убиваю процесс сам.

EDIT5: Используя EDIT4, если я делаю запрос к любой конечной точке, я получаю страницу назад, но бутылка выдает ошибку:

Bottle vx.x.x server starting up (using WSGIRefServer())...
Listening on <URL>
Hit Ctrl-C to quit.


----------------------------------------
Exception happened during processing of request from ('<IP>', 55104)

Я бы отключил команду от стандартного потока ввода / вывода и ошибок:

nohup python3 -u <script> </dev/null >/dev/null 2>&1 &  

sshнужен индикатор, который больше не выводит и не требует ввода. Имея что-то еще на входе и перенаправляя средства вывода, sshможно безопасно выйти, так как ввод / вывод не поступает или не идет к терминалу. Это означает, что ввод должен происходить откуда-то еще, а вывод (как STDOUT, так и STDERR) должен идти куда-то еще.

</dev/nullЧасть определяет в /dev/nullкачестве входных данных для <script>. Почему это полезно здесь:

Перенаправление / dev / null в stdin даст немедленный EOF любому вызову чтения из этого процесса. Обычно это полезно для отсоединения процесса от tty (такой процесс называется демоном). Например, при удаленном запуске фонового процесса через ssh вы должны перенаправить стандартный ввод, чтобы процесс не ожидал локального ввода. /programming/19955260/what-is-dev-null-in-bash/19955475#19955475

В качестве альтернативы, перенаправление из другого входного источника должно быть относительно безопасным, если текущий sshсеанс не нужно держать открытым.

С этой >/dev/nullчастью оболочка перенаправляет стандартный вывод в / dev / null, по существу отбрасывая его. >/path/to/fileтоже будет работать.

Последняя часть 2>&1перенаправляет STDERR в STDOUT.

Есть три стандартных источника ввода и вывода для программы. Стандартный ввод обычно осуществляется с клавиатуры, если это интерактивная программа, или из другой программы, если она обрабатывает вывод другой программы. Программа обычно печатает со стандартным выводом, а иногда печатает со стандартной ошибкой. Эти три файловых дескриптора (вы можете думать о них как о «каналах данных») часто называются STDIN, STDOUT и STDERR.

Иногда они не названы, они пронумерованы! Для них встроены нумерации 0, 1 и 2 в указанном порядке. По умолчанию, если вы явно не называете номер один или номер один, вы говорите о STDOUT.

Принимая во внимание этот контекст, вы можете видеть, что приведенная выше команда перенаправляет стандартный вывод в / dev / null, куда вы можете записать все, что вам не нужно (часто это называется бит-сегмент), а затем перенаправляет стандартную ошибку в стандартный вывод ( Вы должны поставить & перед пунктом назначения, когда вы делаете это).

Поэтому короткое объяснение таково: «Все выходные данные этой команды должны быть заткнуты в черную дыру». Это один хороший способ сделать программу действительно тихой!
Что означает> / dev / null 2> & 1? | Xaprb

Посмотрите на man ssh:

 ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
     [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-L [bind_address:]port:host:hostport]
     [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
     [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
     [user@]hostname [command]

При запуске ssh -i <keyfile> -o StrictHostKeyChecking=no <user>@<hostname> "./startup.sh"вы запускаете сценарий оболочки startup.sh как команда ssh.

Из описания:

Если указана команда, она выполняется на удаленном хосте вместо оболочки входа в систему.

Исходя из этого, он должен запускать скрипт удаленно.

Разница между этим и выполнением nohup python3 -u <script> &в локальном терминале заключается в том, что он запускается как локальный фоновый процесс, в то время как команда ssh пытается запустить его как удаленный фоновый процесс.

Если вы собираетесь запустить скрипт локально, не запускайте startup.sh как часть команды ssh. Вы можете попробовать что-то вродеssh -i <keyfile> -o StrictHostKeyChecking=no <user>@<hostname> && "./startup.sh"

Если вы намерены запустить скрипт удаленно и хотите, чтобы этот процесс продолжался после завершения сеанса ssh, вам сначала нужно будет запустить screenсеанс на удаленном хосте. Затем вы должны запустить скрипт python на экране, и он продолжит работать после того, как вы завершите сеанс ssh.

Смотрите Руководство пользователя экрана

Хотя я думаю, что screen - ваш лучший вариант, если вы должны использовать nohup, shopt -s huponexitперед запуском команды nohup рассмотрите возможность установки на удаленном хосте. Кроме того, вы можете использовать, disown -h [jobID]чтобы отметить процесс, чтобы SIGHUP не отправлялся на него. 1

Как мне продолжить работу после выхода из командной строки в фоновом режиме?

Сигнал SIGHUP (зависание) используется вашей системой при управлении терминалом или прекращении процесса управления. Вы можете использовать SIGHUP для перезагрузки файлов конфигурации и открытия / закрытия файлов журналов. Другими словами, если вы выйдете из своего терминала, все выполняющиеся задания будут прерваны. Чтобы избежать этого, вы можете передать опцию -h команде disown. Эта опция помечает каждый идентификатор задания так, чтобы SIGHUP не отправлялся заданию, если оболочка получает SIGHUP.

Кроме того, ознакомьтесь с кратким описанием того, как huponexitработает, когда оболочка закрывается, удаляется или удаляется. Я предполагаю, что ваша текущая проблема связана с тем, как завершается сеанс оболочки. 2

1. Все дочерние процессы, фоновые или нет оболочки, открытой через ssh-соединение, уничтожаются с помощью SIGHUP, когда ssh-соединение закрывается, только если установлена ​​опция huponexit: запустите shopt huponexit, чтобы проверить, верно ли это.

2. Если huponexit имеет значение true, то вы можете использовать nohup или disown, чтобы отделить процесс от оболочки, чтобы он не был убит при выходе. Или запустить вещи с экрана.

3. Если huponexit имеет значение false, что является значением по умолчанию, по крайней мере, в некоторых linux в наши дни, то фоновые задания не будут уничтожены при обычном выходе из системы.

4. Но даже если huponexit имеет значение false, то, если соединение ssh будет прервано или прервано (отличается от обычного выхода из системы), фоновые процессы все равно будут убиты. Этого можно избежать с помощью disown или nohup, как в (2).

Наконец, вот несколько примеров того, как использовать купированный гупонексит. 3

$ shopt -s huponexit; shopt | grep huponexit
huponexit       on
# Background jobs will be terminated with SIGHUP when shell exits

$ shopt -u huponexit; shopt | grep huponexit
huponexit       off
# Background jobs will NOT be terminated with SIGHUP when shell exits

Может стоит попробовать -nвариант при запуске ssh? Это предотвратит зависимость удаленного процесса от локального stdin, который, конечно же, закроется, как только ssh sessionзакончится. И это приведет к удаленному прекращению цен, когда он попытается получить к нему доступ stdin.

Я подозреваю, что у вас есть состояние гонки. Было бы что-то вроде этого:

• SSH соединение начинается
• SSH запускает startup.sh
• startup.sh запускает фоновый процесс (nohup)
• startup.sh заканчивается
• ssh завершает работу, и это убивает дочерние процессы (т.е. nohup)

Если бы ssh не сократил ситуацию, произошло бы следующее (не уверен насчет порядка этих двух):

• nohup запускает ваш скрипт на python
• nohup отключается от родительского процесса и терминала.

Таким образом, последние два критических шага не выполняются, потому что startup.sh и ssh заканчивают работу до того, как nohup успевает сделать свое дело.

Я ожидаю, что ваша проблема исчезнет, ​​если вы поместите несколько секунд сна в конец файла startup.sh. Я не уверен, сколько именно вам нужно времени. Если важно свести это к минимуму, то, возможно, вы можете посмотреть что-то в proc, чтобы увидеть, когда это безопасно.

Это больше похоже на проблему с тем, что делает pythonскрипт или pythonсам по себе. Все, что на nohupсамом деле делает (исключая перенаправления), это просто устанавливает обработчик для HUPсигнала SIG_IGN(игнорировать) перед запуском программы. Ничто не мешает программе установить ее обратно SIG_DFLили установить собственный обработчик после запуска.

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

( nohup python3 -u <script> & )

Еще одна вещь, которую также стоит попробовать (если вы используете, bashа не другую оболочку), это использовать disownвместо встроенной nohup. Если все работает так, как задокументировано, это на самом деле не должно иметь никакого значения, но в интерактивной оболочке это остановит распространение HUPсигнала в ваш pythonсценарий. Вы можете добавить disown на следующей строке или на той же, что и ниже (обратите внимание, что добавление ;после a &означает ошибку в bash):

python3 -u <script> </dev/null &>/dev/null & disown

Если вышеперечисленное или какая-то его комбинация не работает, то, безусловно, единственное место, где можно решить проблему, - это pythonсам скрипт.

Я думаю, что это потому, что работа связана с сессией. Как только это заканчивается, любые пользовательские задания также заканчиваются.

Если вы nohupможете открыть его выходной файл, вы можете иметь подсказку nohup.out. Это возможно pythonне по пути, когда вы запускаете скрипт через ssh.

Я хотел бы попытаться создать файл журнала для команды. Попробуйте использовать:

nohup /usr/bin/python3 -u <script> &>logfile &