На странице руководства это просто говорит:
-m Управление заданиями включено.
Но что это на самом деле означает?
Я столкнулся с этой командой в одном вопросе , у меня та же проблема, что и у OP, а именно: "fabric не может запустить tomcat". И set -mрешил это. ОП объяснил немного, но я не совсем понимаю:
Проблема была в фоновых задачах, поскольку они будут убиты, когда команда закончится.
Решение простое: просто добавьте "set -m;" префикс перед командой.
Ответы:
Цитирование документации bash (из man bash):
JOB CONTROL
Job control refers to the ability to selectively stop
(suspend) the execution of processes and continue (resume)
their execution at a later point. A user typically employs
this facility via an interactive interface supplied jointly
by the operating system kernel's terminal driver and bash.
Таким образом, проще говоря, наличие set -m(по умолчанию для интерактивных оболочек) позволяет использовать встроенные модули, такие как fgи bg, которые будут отключены в set +m(по умолчанию для неинтерактивных оболочек).
Однако для меня не очевидно, какова связь между управлением заданиями и уничтожением фоновых процессов при выходе, но я могу подтвердить, что есть одно: запуск set -m; (sleep 10 ; touch control-on) &создаст файл, если он выйдет из оболочки сразу после ввода этой команды, но set +m; (sleep 10 ; touch control-off) &не будет.
Я думаю, что ответ лежит в остальной документации для set -m:
-m Monitor mode. [...] Background pro‐
cesses run in a separate process group and a line con‐
taining their exit status is printed upon their comple‐
tion.
Это означает, что фоновые задания, запущенные под set +m, не являются фактическими «фоновыми процессами» («Фоновые процессы - это те, чей идентификатор группы процессов отличается от идентификатора терминала»): они имеют тот же идентификатор группы процессов, что и оболочка, которая их запустила, а не имеют свои собственные группа процессов, как правильные фоновые процессы. Это объясняет поведение, наблюдаемое при выходе из оболочки перед некоторыми из ее фоновых заданий: если я правильно понимаю, при выходе сигнал отправляется процессам в той же группе процессов, что и оболочка (таким образом, уничтожение фоновых заданий, запущенных в set +m), но не к тем из других групп процессов (таким образом, оставляя в покое истинные фоновые процессы, запущенные под set -m)
Итак, в вашем случае startup.shскрипт предположительно запускает фоновое задание. Когда этот сценарий выполняется неинтерактивно, например, через SSH, как в вопросе, с которым вы связаны, управление заданиями отключается, «фоновое» задание разделяет группу процессов удаленной оболочки и, таким образом, уничтожается при выходе из оболочки. И наоборот, включив управление заданиями в этой оболочке, фоновое задание получает свою собственную группу процессов и не уничтожается при выходе из родительской оболочки.
Я нашел это в списке вопросов GitHub, и я думаю, что это действительно ответит на ваш вопрос.
На самом деле это не проблема SSH, это более тонкое поведение неинтерактивных / интерактивных режимов BASH и распространения сигналов в группы процессов.
Следующее основано на /programming/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 запущенного процесса и продолжает работать до тех пор, пока к сокетам ничего не подключено и его дочерние элементы не завершены. Хороший процесс deamon гарантирует, что он не будет ждать, пока его дочерние элементы завершат работу дочернего процесса, а затем завершат работу. В этом режиме SSH не отправляет SIGHUP дочернему процессу. Я полагаю, что это будет работать правильно для большинства сценариев, выполняющих процесс, который выполняет деамонизацию сам по себе и не нуждается в фоновом режиме. В тех случаях, когда сценарии инициализации используют '&' для фонового процесса, вероятно, основная проблема будет в том, будет ли когда-либо фоновый процесс пытаться читать из stdin, так как это вызовет SIGHUP, если сеанс был завершен.
pty / tty = true *
Если сценарий инициализации служит фоном для запуска процесса, родительская оболочка BASH вернет код выхода в соединение SSH, которое, в свою очередь, будет ожидать немедленного завершения, поскольку не ожидает завершения дочернего процесса и не блокируется на stdout. / STDERR / STDIN. Это приведет к отправке SIGHUP в родительскую группу процессов оболочки bash, которая, поскольку управление заданиями отключено в неинтерактивном режиме в bash, будет включать только что запущенные дочерние процессы. Если процесс-демон явно запускает новый сеанс процесса при разветвлении или в разветвленном процессе, то он или его дочерние элементы не получат SIGHUP от выхода родительского процесса BASH. Обратите внимание, что это отличается от приостановленных заданий, которые будут видеть SIGTERM. Я подозреваю, что проблемы, связанные с этой единственной работой, иногда связаны с небольшим состоянием гонки. http://www.itp.uzh.ch/~dpotter/howto/daemonize , вы увидите, что в коде новый сеанс создается разветвленным процессом, который не может быть запущен до выхода из родительского процесса, что приводит к случайному поведение успех / неудача, упомянутое выше. Оператор сна даст достаточно времени для того, чтобы разветвленный процесс создал новый сеанс, поэтому он работает в некоторых случаях.
pty / tty = true и контроль заданий явно включен в bash
SSH не будет подключаться к stdout / stderr / stdin оболочки bash или любых запущенных дочерних процессов, что будет означать, что он завершится, как только родительская оболочка bash закончит выполнение запрошенных команд. В этом случае, при явном включении управления заданиями, любые процессы, запущенные оболочкой bash с '&' для их фоновой обработки, будут немедленно помещены в отдельный сеанс и не получат сигнал SIGHUP, когда родительский процесс в сеансе BASH завершится ( SSH соединение в этом случае).
Что нужно исправить
Я думаю, что решения должны быть явно упомянуты в документации по операциям run / sudo как особый случай при работе с фоновыми процессами / сервисами. В основном либо используйте 'pty = false', либо, если это невозможно, явно включите управление заданиями в качестве первой команды, и поведение будет правильным.
tomcat/bin/startup.shсвязано сfg/bg?