Для стандартной оболочки (bash) (POSIX.1)

Начните с & , сделайте чтение из другого затем по умолчанию stdin (== / dev / tty == / dev / stdin == / dev / fd / 0 ) + сделать так, чтобы он записывал что-нибудь кроме stdout по умолчанию (== / dev / tty == / dev / stdin == / dev / fd / 1 ) (то же самое для stderr ) и убедитесь, что задание не приостановлено или не приостановлено (= остановлено ). Если он должен быть остановлен или должен быть прочитан с терминала и должен продолжаться после того, как терминал задания зависает, убедитесь, что у процессов в задании есть обработчик (ловушка) для сигнала SIGHUP . Если он должен писать на терминал и должен пережить зависание терминала, убедитесь, что у процессов, которые пишут на терминал, есть обработчик для SIGPIPE .

Объяснение:

Фоновые процессы отправляются SIGTTIN в момент попытки чтения с терминала. По умолчанию для SIGTTIN используется остановка (= приостановка) процесса. Зависание терминала приведет к тому, что первое поколение процессов ваших фоновых заданий изменится на init, в результате чего группа процессов первого поколения процессов вашего задания станет потерянной группой процессов. (Осиротевшие группы процессов - это те группы, в которых ни один из членов не имеет родителя в другой группе процессов, но в том же сеансе.) Система отправит всем остановленным (приостановленным) осиротевшим группам процессов SIGHUP , за которым следует SIGCONT (чтобы убедиться, что они получают SIGHUP ) при зависании терминала, потому что по определению ни один из процессов в этой группе процессов не может быть разбужен родителем из того же сеанса. Следовательно, эти процессы должны быть разбужены системой, но в то же время таким образом, чтобы сигнализировать этому процессу, что он был разбужен из-за зависания терминала, а не из-за нормальной работы. SIGHUP - это механизм, который делает это, и по умолчанию для SIGHUP выполняется прерывание.

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

TL; DR Если ваши потерянные группы процессов не приостановлены (через SIGTTIN , ^ Z или иным образом, им не нужно бояться ] SIGHUP , и если они выводят в файл, а не на терминал, на обоих stdout и stderr и читают из файла, а не с терминала, то они не имеют бояться SIGPIPE . Если вы работаете поверх терминального мультиплексора, а не на необработанном терминале, вам не нужно бояться ни SIGHUP ] или SIGPIPE .

Для zsh

я играл с zsh , и оказалось, что в то время как bash ведет себя так, как я описал выше (выше описанное поведение должно соответствовать POSIX.1), zsh отправляет SIGHUP на даже при выполнении фоновых заданий. setopt NO_HUP ] заставляет его (или систему; здесь не уверен) отправлять только SIGHUP in situatio ns, описанный выше.

Для проверки вы можете попробовать запустить что-то вроде:

( rm -f hup; trap 'echo HUP > hup' HUP; sleep 100)

различными способами ( фон, передний план, остановлен ) и отключиться от него. Затем вы можете проверить, был ли создан файл hup , что будет означать, что задание действительно получило SIGHUP .