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

Механизмът за сигнализиране в ядрото на Linux позволява на работещите приложения асинхронно да уведомяват системата, когато възникне ново събитие. Поради своето естество този механизъм за сигнализиране е известен като софтуерни прекъсвания. Точно както хардуерните прекъсвания, сигналите прекъсват нормалния поток на приложението и е непредсказуемо кога приложението ще получи сигнал.

Нека се потопим дълбоко в механизма за сигнализиране в Linux и да разберем какво се случва зад кулисите.

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

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

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

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

Сигнални номера

Сигналите имат различни числови стойности, започващи с една. Например сигнал 1 е a HUP сигнал в почти всяка система, или сигнал 9 е a УБИЙ сигнал.

Използването на тези номера обаче е силно обезкуражено, когато използвате сигнали във вашите приложения. За POSIX сигнали, сигнал.ч файл трябва да бъде в приложението и разработчикът трябва да използва постоянните дефиниции на свързани числа, като напр SIGHUP, SIGKILL, и т.н. вместо.

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

Генериране и изпращане на сигнал

Генерирането на сигнал възниква поради събитие. Изпращането (доставянето) на сигнала към съответното приложение обаче не се извършва едновременно с генерирането на сигнала.

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

Концепцията за чакащ сигнал

През времето от генериране до предаване на сигнала, сигналите са в състояние на готовност. Можете да получите достъп до броя на чакащите сигнали и броя на чакащите сигнали, разрешени за даден процес от /proc/PID/status файл.

# За процес с PID: 2299
cat /proc/2299/status 
# Изход
...
SigQ: 2/31630
...

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

Точното време, в което ще пристигнат сигналите, често е непредвидимо от приложението. Поради това могат да възникнат някои критични прекъсвания по време на всяка операция. Това може да причини големи проблеми за широкомащабно приложение.

За предотвратяване на някои нежелани ситуации като тази е необходимо да използвате сигнални маски. По този начин е възможно да се блокират някои сигнали преди критична операция. На този етап е важно да завършите критичната част и да премахнете дефинираните блокове. Този процес е нещо, на което разработчикът на приложението трябва да обърне внимание.

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

По този начин същите типове сигнали, поставени на изчакване по време на блока, се изпращат до приложението само веднъж, след като блокът бъде премахнат при нормална употреба. При сигналите в реално време ситуацията е различна.

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

Действията по подразбиране могат да варират в зависимост от типа сигнал. Ако приложението, което получава съответния сигнал, няма функция за обработка на сигнали, се изпълнява действието по подразбиране. Понякога това означава прекратяване на приложението и понякога игнориране на сигнала.

Някои сигнали не могат да бъдат уловени на слоя на приложението, тези сигнали винаги изпълняват действието по подразбиране (като сигнала KILL).

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

Следните стойности се основават на an примерна MIPS архитектура:

Жизненият цикъл на сигналите в Linux

Сигналите преминават през три етапа. Те се произвеждат предимно в производствената фаза, от ядрото или какъвто и да е процес и са представени с число. Те работят леко и бързо, тъй като не натоварват допълнително. Но ако погледнете страната на POSIX, ще видите, че сигналите в реално време могат да предават допълнителни данни.

Фазата на доставка на сигналите идва след фазата на производство. Обикновено сигналите достигат до приложението от ядрото възможно най-бързо. Въпреки това, понякога приложенията могат да блокират сигнали, докато извършват критични операции. В такива случаи сигналът остава чакащ, докато транзакцията се осъществи.

Подобно на сигналите, процесите също са неразделна част от екосистемата на Linux. Разбирането какво представляват процесите и как работят е от решаващо значение, ако планирате да станете системен администратор на Linux.

Какво е процес в Linux?

Прочетете Следващото