Зачем нам нужно посылать SIGHUP только что осиротевшей группе процессов, содержащей остановленный процесс?
Использование psacct
События, которые вы ищете, можно найти через psacct . В частности, я бы взглянул на инструмент ac , который показывает учетную информацию о пользователях. Я касаюсь этого в этих вопросах и ответах U&L под названием: Команды для определения уровня использования сервера .
ПРИМЕЧАНИЕ. Это не «услуга» с возможностью подписки, а скорее инфраструктура отслеживания и отчетности, с помощью которой вы можете задавать ей вопросы.
Вы также можете использовать lastcomm (часть psacct, у него есть несколько инструментов в наборе), чтобы узнать, когда данное приложение использовалось пользователем X.
Пример
$ lastcomm rm
rm S root pts/0 0.00 secs Tue Nov 14 00:39
rm S root pts/0 0.00 secs Tue Nov 14 00:39
rm S root pts/0 0.00 secs Tue Nov 14 00:38
Вы нужно немного покопаться в psacct , но на U&L, а также в Google есть много ресурсов по этому поводу, которые должны дать вам то, что вы хотите.
Использование auditd
Другой инструмент, столь же тщетный, как подход psacct к отслеживанию и отчетности, - это auditd . С помощью auditd вы можете запросить, кто и как долго выполняла программу X.
Пример
$ sudo ausearch -x /usr/bin/sudo | head -5
----
time->Sat Dec 7 21:15:15 2013
type=USER_AUTH msg=audit(1386468915.558:419): pid=2189 uid=1000 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="saml" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
----
time->Sat Dec 7 21:15:15 2013
ПРИМЕЧАНИЕ: Выше приведены все записи, в которых кто-то запускал инструмент / usr / bin / sudo .
Ссылки
На самом деле проблема заключается не только в том, что у остановленного процесса не будет шанса быть разбуженным, но и в том, что он будет уведомлен о том, что он осиротел.
В вашей выписке из APUE говорится:
and does the child know that it has been orphaned?
Он не узнал бы, что стал сиротой, если бы только получил сигнал SIGCONT.
На практике отправка дочернему элементу также SIGHUP — это именно тот способ, которым он был выбран, чтобы уведомить его об этом событии.
Кроме того, это согласуется с тем, что некоторые оболочки (например, Bash )делают со своими дочерними элементами, когда сама оболочка получает SIGHUP из-за события отключения :они распространяют такое событие также на свои остановленные дочерние элементы через HUP+CONT, если вы знакомы с этим конкретным случаем. В противном случае, в качестве справки для этого просто см. справочную страницу Bash -, а именно в разделе СИГНАЛЫ.
Такое поведение ядер на практике распространяет особое поведение таких оболочек на любой случай потерянных групп процессов.
Чтобы уточнить свой ответ, я бы начал с того, что сказал вам, что исторически это был просто SIGKILL, а не SIGHUP+SIGCONT.
В какой-то момент такой подход был сочтен слишком жестким. Поступая таким образом, фактически у процессов даже не было бы шансов хотя бы «грациозно умереть», т.е. закончить то, что они делали, высвободить ресурсы и т.д.
Поэтому SIGKILL был изменен на текущий и более изящный подход HUP+CONT, так что не только процессы имеют возможность очиститься после себя, но и могут продолжить работу, если они того пожелают.
Я не эксперт по спецификациям POSIX, но обратите внимание, например, на следующую выдержку из спецификации _выхода ()системного -вызова:
[...], if the termination of a process causes a process group to become orphaned, [...]. Stopped processes within the group would languish forever. In order to avoid this problem, newly orphaned process groups that contain stopped processes are sent a SIGHUP signal and a SIGCONT signal to indicate that they have been disconnected from their session. The SIGHUP signal causes the process group members to terminate unless they are catching or ignoring SIGHUP.
Возможно, это не явное утверждение, но я думаю, что достаточно близко к нему.
Затем обратите внимание, что использование групп процессов не ограничивается управлением заданиями -, осуществляемым только приложениями оболочки. Вы можете иметь процессы, имеющие свой собственный сеанс, такие как типичный процесс «демон», без управляющего терминала, без управляющей оболочки, но при этом сам порождающий несколько дочерних процессов, группируя их в группы процессов, которые можно обрабатывать. (т. е. сигнализированы )с использованием их идентификаторов процесса -группы -.
На самом деле, хотя специфический вариант использования групп процессов для «управления работой оболочки -» является наиболее широко известным и очень часто упоминается как превосходный пример даже в самих спецификациях, фактическое определение POSIX для «группы процессов ” это:
3.296 Process Group
A collection of processes that permits the signaling of related processes. Each process in the system is a member of a process group that is identified by a process group ID. A newly created process joins the process group of its creator.
Общий общий набор процессов.
В то время как определение «управления заданиями»:
3.203 Job Control
A facility that allows users selectively to stop (suspend) the execution of processes and continue (resume) their execution at a later point. The user typically employs this facility via the interactive interface jointly supplied by the terminal I/O driver and a command interpreter.
Управление заданиями — это концепция, относящаяся к интерактивным оболочкам.
Группировка процессов — более широкое понятие.
ХТХ