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.[1].
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.
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.
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.
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.
| [1] |
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. |
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>.