linux - mp3tag - ¿Por qué muchos programas Unix usan señales como USR1?

mp3 tag linux

Question

Muchos programas de Unix aceptan señales como USR1 y USR2 . Por ejemplo, para actualizar el ejecutable de Nginx sobre la marcha, envíe kill -USR2 .

Entiendo que USR1 es una señal "definida por el usuario", lo que significa que quien creó el programa puede usarlo para indicar "cerrar" o "volcar sus registros" o "imprimir foo mil veces" o lo que sea. Pero no entiendo por qué deben usar este nombre arbitrario. ¿Por qué no kill -UPGRADE , o kill -GRACEFUL_SHUTDOWN ? ¿Unix solo permite señales específicas?

Mientras estamos en eso, Nginx también usa las siguientes señales (ver documentation ):

• TERM, INT : cierre rápido
• SALIR : cierre elegante
• HUP :
  • Recarga de configuración
  • Comience los nuevos procesos de trabajo con una nueva configuración
  • Cerrar con gracia los viejos procesos de trabajo
• USR1 : vuelva a abrir los archivos de registro
• USR2 : Ejecutable de actualización sobre la marcha
• WINCH : cierre con gracia los procesos de trabajo

HUP? ¿CABRESTANTE? ¿Cuál es el motivo de estos nombres? ¿Dónde puedo aprender más sobre esto?

Answer 1

En plataformas que cumplen con POSIX, SIGUSR1 y SIGUSR2 son señales enviadas a un proceso para indicar las condiciones definidas por el usuario. Las constantes simbólicas para ellos se definen en el archivo de cabecera signal.h . Los nombres de señal simbólicos se utilizan porque los números de señal pueden variar en todas las plataformas.

SIG es un prefijo común para los nombres de señal. USR es una abreviatura para definido por el usuario.

Answer 2

Intenta kill -l y encuentra la respuesta tú mismo:

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

Answer 3

Las señales disponibles en un OS están definidas por el sistema operativo (generalmente después de POSIX); no son "cadenas" sino constantes enteras con nombres estándar. USR1 y USR2 son las dos señales que no tienen un significado específico adjunto, destinadas para el uso arbitrario que quiera el desarrollador.

En su máquina Linux, lea la man 7 signal para obtener una descripción general de la señalización y las señales.

Puede redefinir el significado de otras señales si está preparado para tratar con el sistema operativo que emite esas señales en respuesta a los eventos. Por ejemplo, puede hacer que HUP signifique "configuración de recarga", siempre que tenga la certeza de que el proceso nunca se paralizará (pérdida de terminal), o que esté preparado para manejar casos donde el SO y no un usuario envía el HUP señal.

Answer 4

Los nombres de las señales se originan desde tiempos anteriores a Posix.

Quiero hablar sobre SIG ** IOT **. En los tiempos en que se utilizaban los mainframes DEC PDP, los procesadores utilizados tenían una instrucción IOT especial (Trampa de E / S) que a menudo se utilizaba para bloquear el sistema suavemente , por lo general forzándolo a reiniciarse (en servidores en tiempo real). El kernel completo junto con los controladores del dispositivo y los procesos privilegiados (escritos en ensamblador) usaron este método. Incluso hoy, hay procesadores que todavía tienen esta instrucción IOT.

Entonces, cuando kernel experimenta una ejecución de una instrucción IOT en un dominio no privilegiado, genera un SIGIOT para el proceso afectado.

Answer 5

Porque los nombres de las señales están estandarizados (por POSIX). Puedes escribir tu propio ejecutable kill-type para tomar -UPGRADE si quieres y hacer que entregue la señal USR1 , pero el kill estándar que viene con UNIX no lo reconocerá.

Alternativamente, puede crear un alias, función o script de shell para hacer la traducción por usted, como con el alias bash :

alias upgrade=''kill -USR1''

El signal.h cabecera signal.h asigna los nombres de señal a sus valores reales, que dependen de la implementación.

En términos de WINCH , lo considero un poco abominable. Esta es la señal que se envía a las aplicaciones cuando cambia el tamaño de la ventana (específicamente cuando cambia la ventana de su terminal de control).

Usarlo para cerrar con gracia los hilos de trabajo no es una buena idea a menos que pueda garantizar que el proceso nunca se ejecutará en un terminal. Sé que estaría bastante molesto si estuviera ejecutando una aplicación y decidiera cancelar todo el trabajo en vuelo solo porque maximice la ventana :-)

Answer 6

HUP es la abreviatura de "cuelgue". Esta señal se envía a un proceso si su terminal de control llega al final del archivo. En los viejos tiempos, los terminales de control generalmente se conectaban a puertos serie, posiblemente a través de un enlace de módem a través de una línea telefónica. Si la conexión telefónica se colgara, el módem local bajaría la línea de Detección de portadora, lo que daría como resultado que el kernel informara el fin del archivo y se SIGHUP una señal SIGHUP .

WINCH es la abreviatura de "cambio de ventana". Se envía a un proceso si su terminal de control cambia de tamaño. Por razones obvias, los terminales que pueden cambiar de tamaño suelen ser pseudo-terminales representados finalmente por un emulador de terminal que se ejecuta en un entorno de ventana (como xterm ).