Кто-то может объяснить подробно, что “устанавливает-m”, делает?
Обнаружьте свойства каждого последовательного порта. Посмотрите на поставщика и образцовые строки. Например,
# udevadm info --query="property" --name=/dev/ttyUSB0**
UDEV_LOG=3
DEVPATH=/devices/platform/orion-ehci.0/usb1/1-1/1-1:1.0/ttyUSB0 /tty/ttyUSB0
MAJOR=188
MINOR=0
DEVNAME=/dev/ttyUSB0
SUBSYSTEM=tty
ID_PORT=0
ID_PATH=platform-orion-ehci.0-usb-0:1:1.0
ID_VENDOR=FTDI
ID_VENDOR_ENC=FTDI
ID_VENDOR_ID=0403
ID_MODEL=FT232R_USB_UART
ID_MODEL_ENC=FT232R\x20USB\x20UART
ID_MODEL_ID=6001
ID_REVISION=0600
ID_SERIAL=FTDI_FT232R_USB_UART_A40135O1
ID_SERIAL_SHORT=A40135O1
ID_TYPE=generic
ID_BUS=usb
ID_USB_INTERFACES=:ffffff:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=ftdi_sio
ID_IFACE=00
ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd
ID_MODEL_FROM_DATABASE=FT232 USB-Serial (UART) IC
DEVLINKS=/dev/char/188:0 /dev/serial/by-path/platform-orion-ehci.0-usb-0:1:1.0-port0 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A40135O1-if00-port0
Цитирование документации 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.
Итак, проще говоря, установив -m (по умолчанию для
интерактивные оболочки) позволяет использовать встроенные модули, такие как fg и bg ,
который будет отключен в набор + m (по умолчанию для неинтерактивных оболочек).
Для меня не очевидно, какова связь между управлением работой и
тем не менее, уничтожение фоновых процессов на выходе, но я могу подтвердить, что
имеется один: работающий набор -m; (сон 10; сенсорный контроль) &
создать файл, если он выходит из оболочки сразу после ввода
команда, но набор + m; (сон 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.
Это означает, что фоновые задания, начатые при наборах + m , не являются фактическими
«фоновые процессы» («Фоновые процессы те чей процесс
идентификатор группы отличается от идентификатора терминала "): они совместно используют один и тот же процесс
идентификатор группы в качестве оболочки, которая их начала, а не иметь свой собственный
группы процессов, такие как соответствующие фоновые процессы. Это объясняет
поведение, наблюдаемое, когда оболочка выходит из строя до некоторой части ее фона
рабочие места: если я правильно понимаю, при увольнении посылается сигнал
процессы в той же группе процессов, что и оболочка (таким образом убивая
фоновые задания, запущенные в набор + m ), но не в соответствии с заданиями других
группы процессов (оставляя в покое запущенные истинные фоновые процессы)
в set -m ).
Таким образом, в вашем случае сценарий startup.sh , предположительно, запускает
фоновое задание. Когда этот сценарий выполняется неинтерактивно, например
по SSH, как в вопросе, с которым вы связаны, управление заданиями отключено,
фоновое задание совместно использует группу процессов удаленной оболочки, и
таким образом, убивается, как только этот снаряд выходит. И наоборот, путем включения задания
управление в этой оболочке, фоновое задание приобретает свой собственный процесс
группа и не погибает при выходе из родительской оболочки.
Я нашел это в списке проблем на 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, либо , где это невозможно, явно включите управление заданием в качестве первой команды , и поведение будет правильным.