Чому програми Unix не можуть мати сигнали із значущими назвами програм (а не USR1 тощо)?


79

Багато програм Unix приймають такі сигнали, як USR1і USR2. Наприклад, щоб оновити виконуваний файл для Nginx на льоту, ви надсилаєте kill -USR2.

Я розумію, що USR1це "визначений користувачем" сигнал, що означає, що той, хто створив програму, може використовувати його, щоб означати "вимкнути", "скинути ваші журнали" або "надрукувати foo тисячу разів" або що завгодно. Але я не розумію, чому вони повинні використовувати цю довільну назву. Чому ні kill -UPGRADE, чи kill -GRACEFUL_SHUTDOWN? Чи Unix дозволяє лише певні сигнали?

Поки ми до цього прийшли, Nginx також використовує такі сигнали (див. Документацію ):

  • ТЕРМІН, INT : Швидке вимкнення
  • QUIT : Витончене вимкнення
  • HUP :
    • Перезавантаження конфігурації
    • Запустіть нові робочі процеси з новою конфігурацією
    • Витончено вимкніть старі робочі процеси
  • USR1 : Відкрийте знову файли журналів
  • USR2 : оновлення, що виконується на льоту
  • WINCH : Витончено вимикає робочі процеси

HUP? ЛЕБЕДКА? У чому причина цих імен? Де я можу дізнатись більше про це?


1
Про все - цікаво, що nginx використовує QUIT для витонченого вимкнення. Це традиційно схоже на TERM + dump-a-core. TERM здатний до витонченого вимкнення. Все залежить від того, як ви обробляєте сигнали, але .. це дивно, коли розробники виходять з обірваного шляху.
synthesizerpatel

1
TIL: man signalобговорює сигнали та перераховує 31 з них.
Натан Лонг

Відповіді:


80

Сигнали, доступні в ОС, визначаються ОС (зазвичай після POSIX) - це не "рядки", а цілі цілі константи зі стандартними іменами. USR1і USR2є двома сигналами, які не мають певного значення - призначені для будь-якого довільного використання, яке хоче розробник.

На вашому комп'ютері Linux прочитайте man 7 signalогляд обробки сигналів та сигналів.

Ви можете перевизначити значення інших сигналів, якщо готові мати справу з ОС, яка видає ці сигнали у відповідь на події. Ви можете, наприклад, зробити HUPсереднє значення "перезавантажити конфігурацію" - доки ви впевнені, що процес ніколи не призведе до зависання (втрата терміналу), або ви готові розглядати випадки, коли ОС, а не користувач, надсилає сигнал HUP .


22

HUPце скорочення від "зависання". Цей сигнал надсилається в процес, якщо його контрольний термінал досягає кінця файлу. У старі часи контрольні термінали, як правило, підключалися до послідовних портів, можливо, через модемну лінію по телефонній лінії. Якщо телефонне з'єднання було припинено, локальний модем опустив би лінію виявлення несучої, що призведе до того, що ядро ​​повідомляє про кінець файлу і SIGHUPнадсилає сигнал.

WINCHце скорочення від "зміна вікна". Він надсилається в процес, якщо його контрольний термінал змінює розмір. З очевидних причин термінали, які можуть змінювати розмір, зазвичай є псевдотерміналами, в кінцевому рахунку представлені емулятором терміналів, що працює в середовищі вікон (наприклад xterm).


10

Спробуйте kill -lзнайти відповідь самі:

1)  SIGHUP       2)  SIGINT       3)  SIGQUIT      4)  SIGILL       5)  SIGTRAP
6)  SIGABRT      7)  SIGBUS       8)  SIGFPE       9)  SIGKILL      10) SIGUSR1
11) SIGSEGV      12) SIGUSR2      13) SIGPIPE      14) SIGALRM      15) SIGTERM
16) SIGSTKFLT    17) SIGCHLD      18) SIGCONT      19) SIGSTOP      20) SIGTSTP
21) SIGTTIN      22) SIGTTOU      23) SIGURG       24) SIGXCPU      25) SIGXFSZ
26) SIGVTALRM    27) SIGPROF      28) SIGWINCH     29) SIGIO        30) SIGPWR
31) SIGSYS       34) SIGRTMIN     35) SIGRTMIN+1   36) SIGRTMIN+2   37) SIGRTMIN+3
38) SIGRTMIN+4   39) SIGRTMIN+5   40) SIGRTMIN+6   41) SIGRTMIN+7   42) SIGRTMIN+8
43) SIGRTMIN+9   44) SIGRTMIN+10  45) SIGRTMIN+11  46) SIGRTMIN+12  47) SIGRTMIN+13
48) SIGRTMIN+14  49) SIGRTMIN+15  50) SIGRTMAX-14  51) SIGRTMAX-13  52) SIGRTMAX-12
53) SIGRTMAX-11  54) SIGRTMAX-10  55) SIGRTMAX-9   56) SIGRTMAX-8   57) SIGRTMAX-7
58) SIGRTMAX-6   59) SIGRTMAX-5   60) SIGRTMAX-4   61) SIGRTMAX-3   62) SIGRTMAX-2
63) SIGRTMAX-1   64) SIGRTMAX

9

Оскільки назви сигналів стандартизовані (за допомогою POSIX). Ви можете написати власний виконуваний файл типу kill, щоб взяти його, -UPGRADEякщо хочете, і попросити його подати USR1сигнал, але стандарт, killщо постачається з UNIX, не розпізнає його.

Крім того, ви можете створити псевдонім, функцію або сценарій оболонки, щоб зробити переклад за вас, наприклад, з bashпсевдонімом:

alias upgrade='kill -USR1'

Файл signal.hзаголовка відображає імена сигналів до їх фактичних значень, які залежать від реалізації.

З точки зору WINCH, я вважаю це трохи огидною. Це сигнал, який надходить до програм, коли змінюється розмір їх вікна (зокрема, коли змінюється вікно контрольного терміналу).

Використовувати його для витонченого завершення робочих потоків - це не гарна ідея, якщо ви не гарантуєте, що процес ніколи не буде запускатися в терміналі. Я знаю, що я б дуже збентежився, якщо б запускав програму, і вона вирішила скасувати всі роботи в польоті лише тому, що я максимально розгорнула вікно :-)


1
Ах - звичайно, killсама по собі програма, про яку б не знали -UPGRADE. Я про це не думав. :)
Натан Лонг

5

На POSIX-сумісних платформ, SIGUSR1і SIGUSR2сигнали , послані до процесу , щоб вказати певні користувачем умови. Символічні константи для них визначені у файлі заголовка signal.h. Символічні назви сигналів використовуються, оскільки номери сигналів можуть змінюватися на різних платформах.

SIGє загальним префіксом для імен сигналів. USR- це абревіатура, що визначається користувачем.


3
Одним із прикладів цього є додаткові варіанти {2,3,4}, fsckякі на USR1 почнуть друкувати інформацію про хід і зупиняться на USR2. Надзвичайно зручно, коли у вас є проблеми з файловою системою, завантажтесь із cd-файлу для порятунку, запустіть fsck, щоб виправити проблему, а потім через деякий час, коли ви починаєте нудьгувати чекати, зрозумійте "блін, я повинен був вказати якийсь параметр, щоб увімкнути інформацію про хід ".
hlovdal

5

Назви сигналів походять з більш ранніх часів, ніж Posix.

Я хочу поговорити про SIG ** IOT **. У часи, коли використовувались мейнфрейми DEC PDP, використовувані процесори мали спеціальну інструкцію IOT (I / O Trap), яка часто використовувалася для м'якого збою системи, як правило, змушуючи її перезавантажуватися (на серверах реального часу). Це ядро, разом із драйверами пристроїв та привілейованими процесами (написаними на асемблері), використовувало цей метод. Навіть сьогодні існують процесори, які все ще мають цю інструкцію IOT.

Отже, коли ядро ​​переживає виконання інструкції IOT у непривілейованому домені, воно піднімає SIGIOT до ураженого процесу.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.