Процесс убит перед запуском в фоновом режиме

Я использую скрипт bash, script.shсодержащий команду cmd, запущенную в фоновом режиме:

#!/bin/bash
…
cmd &
…

Если я открываю эмулятор терминала и запускаю script.sh, cmdон корректно выполняется в фоновом режиме, как и ожидалось. То есть, пока script.shзакончился, cmdпродолжает работать в фоновом режиме, с PPID 1.

Но, если я открываю другой эмулятор терминала (скажу xfce4-терминал) от предыдущей (или в начале рабочего стола сессии, которая является моим реальным случаем использования), а также выполнять script.shпо

xfce4-terminal -H -x script.sh

cmdбольше не выполняется должным образом: он убит прекращением script.sh. Использование nohupдля предотвращения этого недостаточно. Я обязан поставить sleepкоманду после нее, иначе cmdон погибнет от прекращения действия script.sh, прежде чем от него отмежеваться.

Единственный способ , которым я нашел , чтобы cmdправильно выполнить в фоновом режиме, чтобы положить set -mв script.sh. Зачем это нужно в этом случае, а не в первом? Почему такая разница в поведении между двумя способами выполнения script.sh(и, следовательно, cmd)?

Я полагаю , что в первом случае, режим монитора не активируется, как можно видеть, поставив set -oв script.sh.

Процесс, cmdв котором предполагается запускаться, будет прерван SIGHUPсигналом между fork () и exec (), и любая nohupоболочка или другой материал не будет иметь возможности для запуска и будет иметь какой-либо эффект. (Вы можете проверить это с помощью strace)

Вместо того nohup, вы должны установить SIGHUPв SIG_IGN(игнорировать) в родительской оболочке перед выполнением вашей команды фона; если для обработчика сигнала установлено значение «игнорировать» или «по умолчанию», такое расположение будет наследоваться через fork () и exec (). Пример:

#! /bin/sh
trap '' HUP    # ignore SIGHUP
xclock &
trap - HUP     # back to default

Или же:

#! /bin/sh
(trap '' HUP; xclock &)

Если вы запустите этот скрипт с помощью xfce4-terminal -H -x script.sh, фоновая команда ( xclock &) не будет уничтожена SIGHUPотправленным при script.shзавершении.

Когда лидер сеанса (процесс, который «владеет» управляющим терминалом, script.shв вашем случае) завершается, ядро ​​отправит a SIGHUPвсем процессам из своей группы процессов переднего плана ; но set -mвключит управление заданиями, а начатые команды &будут помещены в группу фоновых процессов, и они не будут сигнализироваться SIGHUP.

Если управление заданиями не включено (по умолчанию для неинтерактивного сценария), команды, запущенные с, &будут запускаться в той же группе процессов переднего плана , а режим «фона» будет имитироваться путем перенаправления их ввода /dev/nullи разрешения их игнорировать SIGINT и SIGQUIT.

Процессы запускаются таким образом из сценария, который когда-то выполнялся как задание переднего плана, но который уже завершился, также не будет сигнализироваться SIGHUP, поскольку их группа процессов (унаследованная от мертвого родителя) больше не является приоритетной группой в терминале.

Дополнительные примечания:

«Режим удержания», кажется, отличается между xtermи xfce4-terminal(и, возможно, другими терминалами на основе vte). В то время как первый будет держать основную сторону pty открытой, последний разорвёт ее после запуска программы -eили -xвыхода из нее, что приведет к сбою любой записи на ведомую сторону EIO. xtermтакже будет игнорировать WM_DELETE_WINDOWсообщения (то есть не будет закрываться), пока все еще выполняются процессы из группы процессов переднего плана.

Я играл с этим. Я не могу понять это, но вот что я обнаружил. Я использовал сон 3 в качестве моего cmd.

Эти две работы. Я понятия не имею, что lsделает в конце. Скобки и двойные nohup, ну, они делают подпроцесс (я думаю, это то, как nohupработает). Я понятия не имею, почему nohupсамостоятельно не работает.

#!/bin/bash

nohup nohup sleep 3 &
ls #no idea why I need this

а также

#!/bin/bash

(
nohup sleep 3 &
ls #no idea why I need this
)

/bin/trueработает вместо ls. Похоже, нам нужно вызвать внешнюю команду. До сих пор не знаю, почему.