Почему сигнал, который блокируется, не отображается в SigPnd в /proc/pid/status, когда он отправляется

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

Вопрос или проблема

Факт

Сигнал может быть заблокирован, что означает, что он не будет доставлен, пока позже не будет разблокирован. Между временем, когда он сгенерирован и когда он доставлен, сигнал считается ожидающим. Руководство
SigPnd (в /proc/pid/status): Маска (выраженная в шестнадцатеричной системе) сигналов, ожидающих выполнения для потока и для процесса в целом Руководство

==> Таким образом, если сигнал блокируется процессом и я отправляю сигнал в этот процесс, этот сигнал считается “ожидающим” и должен отображаться в SigPnd.

Ситуация

Я заблокировал сигнал, допустим, SIGUSR2, с помощью sigprocmask.

Вот результат /proc/pid/status

SigQ:   0/21148
SigPnd: 0000000000000000
SigBlk: 0000000000000aec
SigIgn: 0000000000000200
SigCgt: 0000000000000000

SigBlk показывает, что SIGUSR2 блокируется

Затем я отправляю SIGUSR2 с использованием kill

Ожидание

SigPnd: 0000000000000aec, потому что SIGUSR2 блокируется, поэтому он не доставляется (то есть ожидает)

Реальность

SigPnd: 0000000000000000

Вопрос

Почему SigPnd не отображается, как я ожидал?

Таким образом, если сигнал блокируется процессом и я отправляю сигнал в этот процесс, этот сигнал считается “ожидающим” и должен отображаться в SigPnd.

Это неверное предположение. Когда процесс блокирует сигнал, эта информация о процессе немедленно сохраняется в ядре. Ядро отбрасывает сигнал с этого момента, и процесс никогда о нем не узнает.

В частности, сигнал KILL очевидно не передается процессу и не приказывает ему убить себя.

Вы можете проверить это с помощью strace.

Вам нужно смотреть на ShdPnd (сигналы, ожидающие выполнения для всего процесса), а не SigPnd (сигналы, ожидающие выполнения для конкретного потока). После отправления SIGUSR2 с помощью kill, если он заблокирован, вы должны увидеть изменение маски ShdPnd с 0000000000000000 на 0000000000000800 (SIGUSR2 — это #12).

Ответ или решение

Вопрос, касающийся отсутствия ожидаемого сигнала в SigPnd в /proc/pid/status после его отправки, затрагивает основы работы с сигналами в Linux и требует понимания различных уровней их обработки системой. Давайте более детально разберем, почему ожидания не всегда совпадают с реальностью, а также как правильно интерпретировать данные из /proc/pid/status.

Теория

Основы работы с сигналами

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

Сгенерированный, но заблокированный: Если сигнал сгенерирован, но заблокирован, он не будет обработан процессом до тех пор, пока его не разблокируют. В этот период он считается "ожидающим".
Поставленный в очередь: Некоторые сигналы могут быть поставлены в очередь для последующей обработки.
Обработанный: Сигнал доставлен и обработан процессом.

Файл /proc/pid/status

Файл /proc/pid/status содержит множество полезной информации о процессе, включая информацию о сигналах:

SigPnd: Маска сигналов, ожидающих обработки конкретным потоком.
ShdPnd: Маска сигналов, ожидающих обработки процессом в целом.
SigBlk: Маска заблокированных сигналов.

Пример

Когда вы блокируете сигнал с использованием sigprocmask, данный сигнал добавляется в маску SigBlk. Если вы отправляете этот сигнал с помощью команды kill, он должен появиться в SigPnd, если адресован конкретному потоку, или в ShdPnd, если адресован процессу в целом.

Контекст, который вы описываете, предполагает, что вы ожидали увидеть SIGUSR2 в SigPnd, но вместо этого его место должно быть в ShdPnd. Это связано с тем, что SIGUSR2 был адресован всему процессу. Чтобы увидеть ожидаемые изменения, вам нужно обратить внимание на ShdPnd.

Применение

Как правильно мониторить состояние сигналов

Проверка маски ShdPnd: Посмотрите, как изменяется ShdPnd, когда вы посылаете SIGUSR2. Вы должны увидеть изменения в этой маске, а не в SigPnd. Это указывает на то, что данный сигнал был поставлен на ожидание процессом, но не конкретным потоком.
Использование strace для отладки: С помощью strace можно отследить, как сигналы передаются и фильтруются ядром. Это даст более детальное понимание того, что происходит с сигналом после его отправки.
Осведомленность об архитектуре потоков: В зависимости от того, как ваше приложение обрабатывает потоки, сигналы могут управляться разными частями вашего кода. Убедитесь, что ваш код корректно обрабатывает блокировку и разблокировку сигналов.

Заключение

Важно понимать, как именно сигналы управляются в Linux, чтобы избежать недоразумений, подобных вашему случаю. Путем изучения различий между SigPnd и ShdPnd, а также используя инструменты для отладки, вы сможете добиться полной прозрачности в процессе управления сигналами в вашем приложении. Это позволит не только корректно интерпретировать данные из /proc/pid/status, но и разработать более устойчивые и надежные приложения.