3.8. Dæmons, señales y cómo matar procesos
Anterior | Capítulo 3. Conceptos básicos de Unix | Siguiente

## 3.8. Dæmons, señales y cómo matar procesos

cuando ejecuta un editor es fácil controlarlo, decirle que cargue ficheros y demás. Puede hacerse porque el editor permite ese control y porque el editor depende de una terminal. Algunos programas no están diseñados para ejecutarse entradas continuas por parte del usuario, así que se desconectan de la terminal a la primera oportunidad. Por ejemplo, un servidor web pasa todo el dia respondiendo peticiones web y normalmente no necesita que usted le haga caso. Los programas que transportan correo electrónico de un sitio a otro son otro ejemplo de esta clase de aplicación.

Llamamos a estos programas dæmons. Los Dæmons eran personajes de la mitología griega; no eran ni buenos ni malos, eran pequeños espíritus sirvientes que, en gran medida, hacían cosas útiles por la humanidad. Algo muy parecido a cómo los servidores web y los servidores de correo hacen hoy día tantas cosas útiles para nosotros. Por eso, desde hace mucho tiempo la mascota de BSD es ese dæmon de aspecto tan ufano con su tridente y su cómodo calzado deportivo.

Hay una norma según la cual se da nombre a los programas que suelen ejecutarse como dæmons con una «d» final. BIND es el dæmon de nombres de Berkeley (y el programa que en realidad se ejecuta se llama `named`); el servidor web Apache se llama `httpd`, el dæmon de «spool» de impresora de línea es `lpd` y así sucesivamente. Se trata de un acuerdo, no una ley férrea; por ejemplo el dæmon principal de correo de Sendmail se llama `sendmail`, y no `maild`, como podría suponerse visto lo precedente.

Algunas veces necesitará comunicarse con un dæmon. Estas comunicaciones se denominan señales; es posible comunicarse con un dæmon (o con cualquier otro proceso ejecutándose) mandándole una señal. Existen diversos tipos de señales diferentes que puede mandar: algunas tienen un significado especial, otras son interpretadas por la aplicación y la documentación de la aplicación le dirá cómo interpreta la señal esa aplicación). Solamente puede enviar una señal a un del que sea usted propietario. Si manda una señal a un proceso de otro usuario con kill(1) o kill(2) verá un mensaje del sistema en el que se le comunica que no tiene permiso para hacer tal cosa. La excepción a esto es el usuario `root`, que puede mandar señales a los procesos de cualquier usuario del sistema.

FreeBSD también enviará señales de aplicación en determinados casos. Si una aplicación está mal escrita y trata de acceder a memoria a la que no está previsto que acceda FreeBSD manda al proceso la señal Violación de segmento (`SIGSEGV`). Si una aplicación ha utilizado la llamada de sistema alarm(3) para ser avisada después de que un periodo de tiempo haya transcurrido se le mandará la señal de alarma (`SIGALRM`), y así sucesivamente.

Hay dos señales que pueden usarse para detener un proceso, `SIGTERM` y `SIGKILL`. `SIGTERM` es la manera amable de matar un proceso; el proceso puede recibir la señal, darse cuenta que usted quiere que se apague, cerrar cualquier fichero de log que pueda tener abierto y generalmente terminar cualquier tarea que esté realizando en ese momento antes de apagarse. En algunos casos un proceso puede incluso ignorar `SIGTERM` si se encuentra inmerso en una tarea que no puede ser interrumpida.

Por el contrario, un proceso no puede ignorar una señal `SIGKILL`. Esta es la señal «No me importa lo que estás haciendo, detente ahora mismo». Si manda un `SIGKILL` a un proceso FreeBSD detendrá ese proceso inmediatamente.[4].

Otras señales que puede usar: `SIGHUP`, `SIGUSR1` y `SIGUSR2`. Son señales de propósito general, y aplicaciones diferentes pueden hacer cosas diferentes cuando se utilicen.

Suponga que ha cambiado el fichero de configuración de su servidor web; es un buen momento para decirle al servidor web que lea y aplique la configuración. Podría detener y reiniciar `httpd`, pero esto implicaría un período breve de suspensión del servicio de su servidor web, lo cual puede no ser asumible. La mayoría de los dæmons fueron creados pensando en que fueran capaces de responder a la señal `SIGHUP` releyendo su fichero de configuración. En lugar de matar y reiniciar `httpd` le podría mandar la señal `SIGHUP`. Dado que no hay una manera estándar para responder a estas señales, diferentes dæmons tendrán diferente comportamiento, así que asegúrese de leer la documentación del dæmon en cuestión.

Las señales se envian mediante kill(1), como puede verse en el siguiente ejemplo.

Procedimiento 3.1. Envío de una señal a un proceso

Este ejemplo muestra como enviar una señal a inetd(8). El fichero de configuración de `inetd` es `/etc/inetd.conf` e `inetd` releerá dicho fichero de configuración cuando se le envíe un `SIGHUP`.

1. Identifique el ID de proceso del proceso al que quiere enviarle la señal mediante ps(1) y grep(1). grep(1) se usa para buscar cadenas de texto de su elección en la salida estándar. Puede ejecutarse como un usuario normal, mientras que inetd(8) se ejecuta como `root`, así que debe pasarle los parámetros `ax` a ps(1).

   `%` `ps -ax | grep inetd` 198 ?? IWs 0:00.00 inetd -wW

   Vemos que el PID de inetd(8) es 198. En algunos casos `grep inetd` también puede aparecer en esta salida. Esto se debe a la manera en que ps(1) tiene que encontrar la lista de procesos ejecutándose.

2. Utilice kill(1) para enviar la señal. Debido a que inetd(8) está siendo ejecutado po `root` tendrá que usar primero su(1) para volverse `root`.

   `%` `su` `Password:` `#` `/bin/kill -s HUP 198`

   Del mismo modo que la mayoría de órdenes UNIX® kill(1) no imprimirá ninguna salida si ha funcionado bien. Si envía una señal a un proceso del que no es el propietario verá lo siguiente: kill: `PID`: Operation not permitted. Si no teclea bien el PID puede enviar la señal a un proceso equivocado, lo cual puede ser malo, o si tiene suerte, habrá enviado la señal a un proceso que no está en uso y verá el sistema le dir´ kill: `PID`: No such process.

   ### ¿Por qué utilizar `/bin/kill`?:

   Muchas shells incorporan su propio `kill`; esto es, el shell mandará la señal directamente, en lugar de ejecutar `/bin/kill`. Esto puede ser útil pero las diferentes shells tienen diferentes sintaxis para especificar el nombre de la señal que envían. En lugar de tratar de aprederse todas ellas, es más fácil simplemente usar `/bin/kill `...`` sea la que sea la shell que prefiera usar.

El envío de otras señales es muy similar; sustituya `TERM` o `KILL` en la línea de órdenes según sea necesario.

### Importante:

Matar procesos aleatorios en el sistema es una mala idea. En particular, init(8), ID de proceso 1, es muy especial. Ejecutar `/bin/kill -s KILL 1` es una manera rápida de apagar su sistema. Siempre revise dos veces los argumentos con los que ejecuta kill(1) antes de pulsar Intro.

[4] Esto no es del todo cierto (ciertas cosas no pueden ser interrumpidas. Por ejemplo, si el proceso está tratando de leer desde un fichero que está en otro sistema de la red, y el otro sistema no está disponible por alguna razón (por estar apagada, o que la red tenga un fallo), tenemos un caso de lo que llamamos «proceso ininterrumpible». Más tarde, al proceso se le acabará el tiempo de espera, generalmente pasados dos minutos. Tan pronto como esto ocurra el proceso será liquidado.

Anterior | Subir | Siguiente
3.7. Procesos | Inicio | 3.9. Shells

Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista <questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.