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.
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 inetd198 ?? 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.
%suPassword:#/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.
/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.
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.
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>.