Linux поддерживает как надежные сигналы POSIX (в дальнейшем «стандартные сигналы»), так и сигналы реального времени POSIX.
Использование сигналов в Linux
Сигналы в системе Linux сообщают операционной системе, как обращаться с работающей программой или процессом. Когда вы обычно закрываете программу, это на самом деле посылает сигнал системе, сообщая ей о необходимости закрыть программу. Вы также можете сделать это вручную.
Начните с поиска процесса, который вы хотите завершить. Вы можете сделать это с:
PS Aux | grep -i <имя программы>
Итак, если вы хотите закрыть Firefox из командной строки, это будет:
PS Aux | grep -i firefox
Вы получите огромный список процессов из Firefox, так как это многопоточное приложение. Все в порядке. Ищите базовый процесс для / usr / lib / firefox. Обычно это первый. Как правило, вы будете искать первый результат.
Если вы находите это подавляющим, вы также можете использовать pgrep. Он работает аналогично, но дает только идентификаторы процессов.
pgrep firefox
Самый низкий идентификатор процесса будет базовым процессом, который вам нужен.
Когда он у вас есть, вам нужно найти идентификационный номер процесса. Первым в списке всегда будет пользователь, выполняющий процесс. Далее будет идентификатор процесса. Имея это в виду , вы можете отправить сигнал SIGTERM процессу, чтобы остановить его, используя команду kill .
убить -SIGTERM 4790
Каждый сигнал также имеет соответствующий номер для сокращения. Число для SIGTERM — 15 , поэтому вы можете использовать его так же, как и полное слово.
убить -15 4790
SIGTERM фактически является действием по умолчанию команды kill. В результате вам вообще не нужно указывать это. Просто используйте:
убить 4790
Вы получите точно такой же результат.
Это хорошо, если процесс отзывчивый, но вы, вероятно, не будете останавливать адаптивный процесс таким образом, по крайней мере, не на рабочем столе . Итак, что вы делаете с процессом без ответа? Есть тонна возможных сигналов. Чтобы лучше понять, насколько широк диапазон, посмотрите их.
убить -l
Да, их много. К счастью, вы не будете касаться подавляющего большинства, если не начнете разрабатывать или писать сценарии системного администрирования. Чаще всего, когда SIGTERM не может остановить процесс, не отвечающий на запросы, вы обращаетесь к Linux-эквиваленту CTRL + Alt + Delete , SIGKILL .
В отличие от печально известного менеджера процессов CTRL + ALT + Delete, SIGKILL фактически работает. На самом деле это означает игнорирование всех других факторов и устранение оскорбительного процесса, несмотря ни на что. Это также означает, что SIGKILL может быть опасным, если вы ошиблись.
Начните точно так же, с поиска ID процесса.
pgrep firefox
Теперь вместо использования SIGTERM, чтобы остановить процесс, используйте более разрушительный SIGKILL.
убить -SIGKILL 4790
Даже если процесс полностью заблокирован, он должен закрыться в течение нескольких секунд.
Как и в случае с SIGTERM, есть число, соответствующее SIGKILL. В данном случае это 9 .
убить -9 4790
Как и раньше, процесс должен быть практически мгновенным.
Вы также должны знать о SIGINT . Это прерывание от клавиатуры, и это больше команды, чем вы думаете в командной строке. Когда вы нажимаете CTRL + C, чтобы остановить процесс из окна терминала, вы фактически запускаете SIGINT. Его код равен 2 , и вы можете использовать его, как и другие, с помощью команды kill.
убить -2 4790
Это не так уж часто, так как вы, скорее всего, будете использовать CTRL + C , но это полезно знать.
Это, безусловно, самые распространенные сигналы, с которыми вы сталкиваетесь при ежедневном использовании Linux. Для более технической разбивки других сигналов перейдите к следующему разделу.
Технические детали
Если вы системный администратор или хотите разрабатывать для Linux, вы, вероятно, захотите глубже погрузиться в технические детали, лежащие в основе сигнальной системы в Linux. В следующем разделе рассматривается полная техническая разбивка сигналов Linux. Вам абсолютно не нужна эта информация для использования Linux на рабочем столе, но если вы намереваетесь изучить внутреннюю работу системы, она может оказаться неоценимой.
Стандартные сигналы
Linux поддерживает стандартные сигналы, перечисленные ниже. Несколько номеров сигналов зависят от архитектуры, как указано в столбце «Значение». (Если даны три значения, первое обычно допустимо для alpha и sparc, среднее для i386, ppc и sh, а последнее для mips. A — означает, что сигнал отсутствует в соответствующей архитектуре.)
Записи в столбце «Действие» таблицы определяют действие по умолчанию для сигнала следующим образом:
Термин : Действие по умолчанию — завершить процесс.
Ign : Действие по умолчанию — игнорировать сигнал.
Core : действие по умолчанию — завершить процесс и сбросить ядро.
Стоп : Действие по умолчанию — остановить процесс.
Во-первых, сигналы описаны в оригинальном стандарте POSIX.1.
| Сигнал | Стоимость | действие | Комментарий |
| или смерть контролирующего процесса | |||
| SIGINT | 2 | Срок | Прерывание с клавиатуры |
| SIGQUIT | 3 | ядро | Выйти с клавиатуры |
| SIGILL | 4 | ядро | Незаконная инструкция |
| SIGABRT | 6 | ядро | Прервать сигнал от abort (3) |
| SIGFPE | 8 | ядро | Исключение с плавающей точкой |
| SIGKILL | 9 | Срок | Сигнал убийства |
| SIGSEGV | 11 | ядро | Неверная ссылка на память |
| SIGPIPE | 13 | Срок | Сломанная труба: пиши в трубу без читателей |
| SIGALRM | 14 | Срок | Сигнал таймера от тревоги (2) |
| SIGTERM | 15 | Срок | Сигнал завершения |
| SIGUSR1 | 30,10,16 | Срок | Определяемый пользователем сигнал 1 |
| SIGUSR2 | 31,12,17 | Срок | Определяемый пользователем сигнал 2 |
| SIGCHLD | 20,17,18 | Ign | Ребенок остановлен или прекращен |
| SIGCONT | 19,18,25 | Продолжить, если остановлен | |
| SIGSTOP | 17,19,23 | Стоп | Остановить процесс |
| SIGTSTP | 18,20,24 | Стоп | Стоп набрал в tty |
| SIGTTIN | 21,21,26 | Стоп | ввод tty для фонового процесса |
| SIGTTOU | 22,22,27 | Стоп | вывод tty для фонового процесса |
Сигналы SIGKILL и SIGSTOP не могут быть пойманы, заблокированы или проигнорированы.
Затем сигналы не в стандарте POSIX.1, но описаны в SUSv2 и SUSv3 / POSIX 1003.1-2001.
| Сигнал | Стоимость | действие | Комментарий |
| SIGPOLL | Срок | Pollable событие (Sys V). Синоним SIGIO | |
| SIGPROF | 27,27,29 | Срок | Таймер профилирования истек |
| SIGSYS | 12, -, 12 | ядро | Неверный аргумент для рутины (SVID) |
| SIGTRAP | 5 | ядро | Трассировка / ловушка прерывания |
| SIGURG | 16,23,21 | Ign | Срочное условие на розетке (4.2 BSD) |
| SIGVTALRM | 26,26,28 | Срок | Виртуальный будильник (4.2 BSD) |
| SIGXCPU | 24,24,30 | ядро | Превышено ограничение по времени процессора (4.2 BSD) |
| SIGXFSZ | 25,25,31 | ядро | Превышен предел размера файла (4.2 BSD) |
Вплоть до Linux 2.2 включительно поведение SIGSYS , SIGXCPU , SIGXFSZ и (на архитектурах, отличных от SPARC и MIPS) по умолчанию (SIGBUS ) заключалось в прекращении процесса (без дампа ядра). (В некоторых других Unices действие по умолчанию для SIGXCPU и SIGXFSZ — завершить процесс без дампа ядра.) Linux 2.4 соответствует требованиям POSIX 1003.1-2001 для этих сигналов, завершая процесс с помощью дампа ядра.
Далее различные другие сигналы.
| Сигнал | Стоимость | действие | Комментарий |
| SIGEMT | 7, -, 7 | Срок | |
| SIGSTKFLT | — 16, — | Срок | Ошибка стека на сопроцессоре (не используется) |
| SIGIO | 23,29,22 | Срок | Теперь возможен ввод / вывод (4.2 BSD) |
| SIGCLD | -, -, 18 | Ign | Синоним для SIGCHLD |
| SIGPWR | 29,30,19 | Срок | Отказ питания (система V) |
| SIGINFO | 29, -, — | Синоним SIGPWR | |
| SIGLOST | -, -, — | Срок | Блокировка файла потеряна |
| SIGWINCH | 28,28,20 | Ign | Сигнал изменения размера окна (4.3 BSD, Sun) |
| SIGUNUSED | — 31, — | Срок | Неиспользованный сигнал (будет SIGSYS) |
(Сигнал 29 это SIGINFO / SIGPWR на альфе, но SIGLOST на спарке.)
SIGEMT не указан в POSIX 1003.1-2001, но, тем не менее, появляется в большинстве других Unices, где его действие по умолчанию обычно состоит в том, чтобы завершить процесс с дампом ядра.
SIGPWR (который не указан в POSIX 1003.1-2001) обычно игнорируется по умолчанию в тех других Unix, где он появляется.
SIGIO (который не указан в POSIX 1003.1-2001) по умолчанию игнорируется в некоторых других Unices.
Сигналы в реальном времени
Linux поддерживает сигналы реального времени, как изначально определено в расширениях реального времени POSIX.4 (и теперь включено в POSIX 1003.1-2001). Linux поддерживает 32 сигнала в реальном времени, пронумерованных от 32 ( SIGRTMIN ) до 63 ( SIGRTMAX ). (Программы всегда должны ссылаться на сигналы в реальном времени, используя обозначение SIGRTMIN + n, поскольку диапазон номеров сигналов в реальном времени варьируется в зависимости от Unices.)
В отличие от стандартных сигналов, сигналы реального времени не имеют предопределенных значений: весь набор сигналов реального времени может использоваться для целей, определяемых приложением. (Обратите внимание, что реализация LinuxThreads использует первые три сигнала в реальном времени.)
Действие по умолчанию для необработанного сигнала в реальном времени — завершить процесс приема.
Сигналы в реальном времени отличаются следующим:
- Несколько экземпляров сигналов реального времени могут быть поставлены в очередь. Напротив, если несколько экземпляров стандартного сигнала доставляются, когда этот сигнал в настоящее время заблокирован, то только один экземпляр ставится в очередь.
- Если сигнал отправляется с использованием sigqueue (2), сопровождающее значение (целое число или указатель) может быть отправлено вместе с сигналом. Если процесс приема устанавливает обработчик для этого сигнала с использованием sa_sigaction флага к sigaction (2) , то он может получить эти данные через si_value поле siginfo_t структуры , передаваемой в качестве второго аргумента в обработчик. Кроме того, поля si_pid и si_uid этой структуры могут использоваться для получения PID и реального идентификатора пользователя процесса, отправляющего сигнал.
- Сигналы в реальном времени доставляются в гарантированном порядке. Несколько сигналов реального времени одного типа доставляются в том порядке, в котором они были отправлены. Если разные сигналы реального времени отправляются процессу, они доставляются, начиная с сигнала с наименьшим номером. (То есть сигналы с низким номером имеют наивысший приоритет.)
Если для процесса ожидают как стандартные сигналы, так и сигналы реального времени, POSIX оставляет его неуказанным, который доставляется первым. Linux, как и многие другие реализации, в этом случае отдает приоритет стандартным сигналам.
Согласно POSIX, реализация должна позволять не менее _POSIX_SIGQUEUE_MAX (32) сигналов реального времени ставиться в очередь в процесс. Однако вместо того, чтобы устанавливать ограничение для каждого процесса, Linux устанавливает общесистемное ограничение на количество сигналов в реальном времени, поставленных в очередь, для всех процессов. Этот лимит можно просмотреть (и с привилегиями), изменив его в файле / proc / sys / kernel / rtsig-max . Связанный файл / proc / sys / kernel / rtsig-max можно использовать, чтобы узнать, сколько сигналов реального времени находится в очереди.
В СООТВЕТСТВИИ С
POSIX.1
Используйте человек команды ( % человек ) , чтобы увидеть , как команда используется на вашем конкретном компьютере.