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

• Непривилегированный процесс может отправлять сигнал другому процессу, если реальное или эффективный ID пользователя процесса, отправляющего сигнал, совпадает с реальным или сохраненным установленным ID пользователя процесса, получающего сигнал, как показано на рис. 20.2. Это правило позволяет пользователям отправлять сигналы в запущенные ими программы с установленным ID пользователя независимо от текущего значения действующего ID пользователя целевого процесса. Более того, в Linux и других системах, предоставляющих системный вызов setresuid(), программа с установленным ID пользователя может извлечь преимущество из данного правила. Если установить с помощью setresuid() сохраненный ID пользователя в то же значение, что и реальный ID пользователя, то пользователь — владелец исполняемого файла не сможет оправлять этому процессу сигналы. (Стандарт SUSv3 устанавливает правила, изображенные на рис. 20.2, но в версиях ядра, предшествовавших 2.0, Linux следовала несколько иным правилам, как описано на странице справочника kill(2).)

• Сигнал SIGCONT обрабатывается особым образом. Непривилегированный процесс может послать этот сигнал в любой процесс, запущенный в той же сессии, минуя проверку ID пользователей. Это позволяет оболочкам, управляющим заданиями, повторно запускать остановленные задания (группы процессов), даже если процессы задания изменили значения ID пользователя (иными словами, это привилегированные процессы, которые применили системные вызовы, описанные в разделе 9.7, для изменения учетных данных).

Рис. 20.2. Разрешения, необходимые непривилегированному процессу для отправки сигнала

Если у процесса нет разрешения на отправку сигнала в запрошенный идентификатор процесса pid, то вызов kill() завершается неудачно с установкой значения EPERM в errno. Если аргумент pid задает набор процессов (то есть значение pid — отрицательное число), вызов kill() завершается успешно, если сигнал может быть получен хотя бы одним из указанных процессов. Использование функции kill() продемонстрировано в листинге 20.3 далее.

20.6. Проверка существования процесса

Системный вызов kill() может также служить другой цели. Если параметр sig указан как 0 (так называемый нулевой сигнал), то никакой сигнал не отправляется. Вместо этого функция kill() лишь выполняет проверку ошибок, удостоверяясь в том, есть ли возможность отправки сигнала в процесс. То есть мы можем использовать нулевой сигнал для тестирования наличия процесса с указанным идентификатором. Если отправка нулевого сигнала завершается неудачно, с ошибкой ESRCH, то мы знаем, что процесс не существует. Если же вызов завершается с ошибкой EPERM (означающей, что процесс существует, но мы не обладаем разрешением на отправку в него сигналов) или завершается успешно, узнаем, что процесс существует.

Подтверждение существования конкретного идентификатора процесса не гарантирует, что конкретная программа все еще запущена. Так как ядро повторно использует идентификаторы процессов при рождении и завершении процессов, один и тот же идентификатор в разное время может соответствовать разным процессам. Более того, некий идентификатор процесса может существовать, но при этом быть «зомби» (иными словами, процесс уже завершился, однако его родительский процесс еще не осуществил вызов функции wait() для получения кода завершения этого дочернего процесса, как описано в разделе 26.2).

Для проверки того, запущен ли тот или иной процесс, могут применяться другие методы.

• Системные вызовы wait(). Эти вызовы описываются в главе 26. Они могут быть задействованы, только если наблюдаемый процесс является дочерним по отношению к вызывающему процессу.

Семафоры и исключающие файловые блокировки. Если наблюдаемый процесс удерживает семафор или файловую блокировку, тот факт, что мы можем получить о них информацию, означает, что данный процесс завершен. Описание семафоров можно найти в главе 49, а файловых замков — в главе 51.

Каналы IPC, такие как простые поименованные каналы и каналы FIFO. Мы настраиваем наблюдаемые процессы таким образом, чтобы они удерживали файловые дескрипторые открытыми на запись в канал на протяжении всей жизни процесса. Одновременно процесс, осуществляющий мониторинг, удерживает открытым файловый дескриптор для чтения из канала и знает, что наблюдаемый процесс завершился, если пишущий конец канала закрыт (так как был достигнут конец файла). Процесс, осуществляющий мониторинг, может определить это либо путем чтения собственного файлового дескриптора, либо путем мониторинга дескриптора с помощью одной из техник, описанных в главе 59.