Почему многие программы Unix используют такие сигналы, как USR1?

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

Я понимаю, что USR1 является" определяемым пользователем " сигналом, означающим, что тот, кто создал программу, может использовать его, чтобы означать "выключение" или "сброс ваших журналов" или "печать foo тысячу раз" или что-то еще. Но я не понимаю, почему они должны использовать это произвольное имя. Почему бы и нет kill -UPGRADE или kill -GRACEFUL_SHUTDOWN? Позволяет ли Unix только определенные сигналы?

пока мы на нем, Nginx также использует следующие сигналы (см. документация):

  • ТЕРМИН, INT: быстрое выключение
  • выход: безопасное отключение
  • АП:
    • настройки перезагрузки
    • запуск новых рабочих процессов с новой конфигурацией
    • изящно выключите старого рабочего процессы
  • USR1: откройте файлы журнала
  • USR2 обновление исполняемого файла на лету
  • лебедка: изящно завершите рабочие процессы

ать? Уинч? В чем причина этих имен? Где я могу узнать больше об этом?

6 65
linux nginx unix django-signals

6 ответов:

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

на вашей машине linux, прочитайте man 7 signal обзор обработки сигналов и сигналов.

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

71

HUP сокращенно от "повесить трубку". Этот сигнал посылается процессу, если его управляющий терминал достигает конца файла. В старые времена управляющие терминалы обычно подключались к последовательным портам, возможно, через модемную линию по телефонной линии. Если телефонное соединение было отключено, локальный модем понизит линию обнаружения несущей, что приведет к тому, что ядро сообщит о конце файла и SIGHUP сигнал был послан.

WINCH сокращенно от "изменение окна". Он отправляется процессу, если его управляющий терминал изменяет размер. По очевидным причинам терминалы, которые могут изменять размер, обычно являются псевдотерминалами, в конечном счете представленными эмулятором терминала, работающим в оконной среде (например,xterm).

18

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

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

alias upgrade='kill -USR1'

The signal.h заголовочный файл карты имена сигналов соответствуют их фактическим значениям, которые зависят от реализации.

С точки зрения WINCH, Я считаю это немного кощунство. Это сигнал, который поступает в приложения при изменении размера их окна (в частности, при изменении окна их управляющего терминала).

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

8

попробовать 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
7

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

SIG является общим префиксом для имен сигналов. USR - это сокращение от user-defined.

4

имена сигналов происходят из более ранних времен, чем Posix.

Я хочу поговорить о SIG**IOT**. Во времена, когда использовались мэйнфреймы DEC PDP, используемые процессоры имели специальную инструкцию IOT (I / O Trap), которая часто использовалась для осторожно сбой системы -- обычно заставляя его перезагрузиться (в реальном времени серверов). Все ядро вместе с драйверами устройств и привилегированными процессами (написанными на ассемблере) использовало этот метод. Даже сегодня, есть процессоры, которые еще много инструкция.

Итак, когда ядро испытывает выполнение инструкции IOT в непривилегированном домене, оно вызывает SIGIOT для затронутого процесса.

4