Читаем Linux API. Исчерпывающее руководство полностью

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

Если в остановленный процесс посылается любой другой сигнал, то он на самом деле не будет доставлен до тех пор, пока процесс не будет возобновлен через получение сигнала SIGCONT. Единственным исключением из этого правила является сигнал SIGKILL, который всегда завершает процесс, даже если этот процесс в настоящее время остановлен.

При получении сигнала SIGCONT происходит удаление всех ожидающих процесса стоп-сигналов (иными словами, процесс их даже не видит). Напротив, при доставке любого стоп-сигнала происходит автоматическое удаление ожидающего сигнала SIGCONT. Эти шаги предпринимаются для предотвращения отмены действия SIGCONT последующей доставкой отправленных ранее, но находящихся в режиме ожидания стоп-сигналов и наоборот.

Не изменяйте диспозицию игнорируемых сигналов, генерируемых терминалом

Если на момент запуска программа обнаруживает, что диспозиция сигнала, генерируемого терминалом, была установлена равной SIG_IGN (игнорировать), то в большинстве случаев программа не должна изменять диспозицию такого сигнала. Это правило не является системным требованием, но, скорее, есть соглашение, которого следует придерживаться при написании приложений. Я объясню причины этого в подразделе 34.7.3. Сигналы, для которых действительно это соглашение: SIGHUP, SIGINT, SIGQUIT, SIGTTIN, SIGTTOU и SIGTSTP.

22.3. Прерываемые и непрерываемые состояния сна процесса

Нам необходимо сделать оговорку к ранее сказанному утверждению, что сигналы SIGKILL и SIGSTOP всегда оказывают немедленное действие на процесс. В различные моменты времени ядро может перевести процесс в режим сна, при этом различают два состояния сна.

• TASK_INTERRUPTABLE. Процесс ожидает свершения некоего события. Например, это может быть ожидание ввода с терминала, запись данных в пустой на данный момент канал или увеличение значения семафора в System V. Процесс может провести в этом состоянии очень длительное время. Если сигнал генерируется для процесса, находящегося в этом состоянии, то операция прерывается — и процесс пробуждается доставкой сигнала. При выводе списка процессов с помощью команды ps(1), процессы, находящиеся в состоянии TASK_INTERRUPTABLE, помечены буквой S в поле STAT (статус процесса).

• TASK_UNINTERRUPTABLE. Процесс ожидает свершения события определенного специального класса, например завершения операции дискового ввода-вывода. Если сигнал генерируется для процесса в этом состоянии, то сигнал не будет доставлен до тех пор, пока процесс не выйдет из сна. Процессы в состоянии TASK_UNINTERRUPTABLE при перечислении командой ps(1) помечаются буквой D в поле STAT.

Поскольку процесс находится в состоянии TASK_UNINTERRUPTABLE лишь непродолжительное время, то факт того, что сигнал доставляется только в момент выхода процесса из сна, практически незаметен. Однако в некоторых ситуациях процесс может зависнуть в этом состоянии, возможно, из-за неполадок с оборудованием, проблем NFS или ошибки в коде ядра. В таких случаях сигнал SIGKILL не завершит зависший процесс. Если причина этого состояния не может быть решена иным образом, то для завершения процесса нам потребуется перезагрузить систему.

Состояния TASK_INTERRUPTABLE и TASK_UNINTERRUPTABLE предусмотрены в большинстве реализаций UNIX. Начиная с версии ядра 2.6.25, в Linux появилось также третье состояние, которое призвано разрешить вышеописанную проблему зависшего процесса.

• TASK_KILLABLE. Это состояние аналогично TASK_UNINTERRUPTABLE, с той лишь разницей, что процесс пробуждается из него в случае получения фатального сигнала (то есть сигнала, завершающего процесс). Переписав соответствующие участки кода ядра с учетом этого состояния, можно избежать различных ситуаций, при которых зависший процесс требует перезагрузки системы. Первым участком кода ядра, конвертированным на использование TASK_KILLABLE, была сетевая файловая система NFS.

22.4. Аппаратно генерируемые сигналы

Сигналы SIGBUS, SIGFPE, SIGILL и SIGSEGV могут быть сгенерированы вследствие аппаратного исключения или, что реже, путем отправки через функцию kill(). В случае аппаратного исключения SUSv3 устанавливает поведение процесса как неопределенное, если выполняется возврат из обработчика сигнала или если он блокирует или игнорирует сигнал. Для этого есть следующие причины.