Объяснение генерации и обработки сигналов Linux

Механизм сигнализации в ядре Linux позволяет запущенным приложениям асинхронно уведомлять систему о появлении нового события. Из-за своей природы этот сигнальный механизм обычно известен как программные прерывания. Как и аппаратные прерывания, сигналы прерывают нормальный поток приложения, и непредсказуемо, когда приложение получит сигнал.

Давайте углубимся в механизм сигнализации в Linux и поймем, что происходит за кулисами.

Основные концепции сигналов в Linux

В Linux процессы генерируют сигналы в трех основных ситуациях:

• Когда исключительная ситуация возникает на стороне оборудования. Например, вы можете думать о таких событиях, как попытка приложения получить доступ к области за пределами разрешенное адресное пространство (ошибка сегментации) или генерация машинного кода, включающего деление на ноль операция.
• Такие ситуации, как использование комбинаций клавиш, таких как Ctrl + С или же Ctrl + Z на консоли пользователем, изменяя размер экрана консоли или отправляя сигнал уничтожения.
instagram viewer
• Таймер, установленный в приложении, истекает, лимит ЦП, заданный приложению, высок, данные поступают в открытый файловый дескриптор и т. д.

Концепция сигналов существует с первых версий Unix. Раньше между версиями Unix существовало несколько различий в отношении обработки сигналов. Позже, с стандартизация POSIX созданный для управления сигналами, Linux и другие производные Unix начали следовать этим стандартам. По этой причине концепции сигналов Unix и сигналов POSIX, с которыми вы можете столкнуться в некоторых документах, указывают на различия.

Номера сигналов

Сигналы имеют различные числовые значения, начиная с единицы. Например, сигнал 1 ХУП сигнал почти в каждой системе, или сигнал 9 является УБИЙСТВО сигнал.

Однако использование этих номеров настоятельно не рекомендуется, когда вы используете сигналы в своих приложениях. Для сигналов POSIX сигнал.ч файл должен быть в приложении, и разработчик должен использовать постоянные определения связанных чисел, таких как ПОДПИСАТЬСЯ, СИГКИЛЛ, так далее. вместо.

Если вы изучите /usr/include/signal.h файл в вашей системе, вы можете увидеть дополнительные операции и другие включенные файлы, просмотрев определения значений, таких как __USE_POSIX, __USE_XOPEN, __USE_POSIX199309, так далее. в файле. Вы можете найти доступные номера сигналов в системах Linux в /usr/include/asm-generic/signal.h файл, который вам не нужно включать непосредственно в код вашего приложения.

Генерация и отправка сигналов

Генерация сигнала происходит из-за события. Однако отправка (доставка) сигнала соответствующему приложению не происходит одновременно с генерацией сигнала.

Чтобы сигнал был отправлен приложению, приложение должно быть запущено в данный момент и иметь ресурсы ЦП. Поэтому отправка сигнала конкретному приложению происходит, когда соответствующее приложение снова начинает работать после переключения контекста.

Концепция ожидаемого сигнала

В течение времени от генерации до передачи сигнала сигналы находятся в состоянии ожидания. Вы можете получить доступ к количеству ожидающих сигналов и разрешенному количеству ожидающих сигналов для процесса из /proc/PID/status файл.

# Для процесса с PID: 2299
кошка /proc/2299/статус 
# Выход
...
SigQ: 2/31630
...

Сигнальные маски и блокировка

Приложение часто не может предсказать точное время поступления сигналов. Поэтому во время любой операции могут возникнуть некоторые критические прерывания. Это может вызвать серьезные проблемы для крупномасштабного приложения.

Для предотвращения подобных нежелательных ситуаций необходимо использовать маски сигналов. Таким образом можно заблокировать некоторые сигналы перед критической операцией. На этом этапе важно завершить критическую часть и удалить определенные блоки. На этот процесс следует обратить внимание разработчику приложения.

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

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

Типы сигналов Linux

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

Некоторые сигналы не могут быть захвачены на прикладном уровне, эти сигналы всегда выполняют действие по умолчанию (например, сигнал KILL).

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

Следующие значения основаны на образцовая архитектура MIPS:

Жизненный цикл сигналов в Linux

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

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

Как и сигналы, процессы также являются неотъемлемой частью экосистемы Linux. Понимание того, что такое процессы и как они работают, имеет решающее значение, если вы планируете стать системным администратором Linux.

Что такое процесс в Linux?

Читать дальше