organismo de control (8) - La pgina man

de Linux
Nombre
organismo de control - un demonio de control del software

Sinopsis
de vigilancia [-f | --force] [nombre de archivo -c | --config-file fichero] [-v | --verbose] [-s
| --sync] [-b | --softboot] [-q | - -no-accin]

Descripcin
El ncleo de Linux puede reiniciar el sistema si se detectan problemas graves. Esto se
puede implementar por medio de hardware especial de vigilancia, o por medio de un
organismo de control ligeramente menos fiables slo de software dentro del ncleo. De
cualquier manera, es necesario que haya un demonio que le dice al ncleo del sistema est
funcionando bien. Si el demonio deja de hacer eso, el sistema se reinicia.
perro guardin es un demonio tales. Se abre / dev / perro guardin, y sigue escribiendo a
menudo suficiente para mantener el ncleo de restablecer, al menos una vez por minuto.
Cada escritura retrasa el tiempo de reinicio otro minuto. Despus de un minuto de
inactividad del hardware organismo de control har que el reinicio. En el caso de la
vigilancia de software la capacidad de reiniciar depender del estado de las mquinas y las
interrupciones.
El demonio de vigilancia puede ser detenido sin provocar un reinicio si el dispositivo /
dev / organismo de control se cierra correctamente, a menos que su ncleo est compilado
con la opcin CONFIG_WATCHDOG_NOWAYOUT habilitado.

Las pruebas
El demonio de vigilancia hace varias pruebas para comprobar el estado del sistema:
Est llena la tabla de procesos?
Hay suficiente memoria libre?
Son algunos archivos accesibles?

 Tener algunos archivos modificados dentro de un intervalo dado?

Es la carga de trabajo promedio muy alto?
Se ha producido un desbordamiento de la tabla de archivos?
es un proceso todava se est ejecutando? El proceso se especifica mediante un archivo
pid.
Algunas direcciones IP para hacer ping a responder?
interfaces de red reciben trfico?
La temperatura es demasiado alta? Los datos de temperatura (no siempre disponible).
Ejecutar un comando definido por el usuario para hacer pruebas arbitrarias.
Ejecutar una o ms rdenes de prueba / reparacin que se encuentran en /etc/watchdog.d.
Estos comandos son llamados con la prueba de argumento o reparacin.
Si cualquiera de estas comprobaciones falla organismo de control provocar una
desconexin. Si alguna de estas pruebas, excepto el binario definido por el usuario durar
ms de un minuto se reiniciar la mquina, tambin.

opciones
opciones de lnea de comandos disponibles son los siguientes:
-v, --verbose
Establecer el modo detallado. Slo en prctica si se compila con la opcin de
Syslog. Este modo de registro cada varias informaciones en LOG_DAEMON con
LOG_INFO prioridad. Esto es til si desea ver exactamente lo que pas hasta que el
organismo de control reinicia el sistema. Actualmente se registra la temperatura (si
est disponible), el promedio de carga, la fecha de cambio de los ficheros que
comprueba y la frecuencia con que se fue a dormir.
-s, --sync
Intente sincronizar el sistema de archivos cada vez que el proceso est despierto.
Tenga en cuenta que el sistema se reinicie si por alguna razn la sincronizacin dura
ms de un minuto.
-b, --softboot
Soft-arrancar el sistema si se produce un error durante el bucle principal, por
ejemplo, si un archivo determinado no es accesible a travs del stat (2) llamada.
Tenga en cuenta que esto no se aplica a la apertura de / dev / perro guardin y / proc
/ loadavg, que se abri antes de que los principales comience el bucle.
-f, --force

Forzar el uso del intervalo dado o la carga media mxima dada en el fichero de
configuracin.
-c config-file, --config-archivo config-file
Usar config-archivo como el archivo de configuracin en lugar de la
/etc/watchdog.conf predeterminado.
-q, --no-accin
No apagar o reiniciar la mquina. Esto es para propsitos de prueba. Todos los
controles se ejecutan y los resultados se registran como de costumbre, pero no se
toman medidas. Tambin su tarjeta de hardware o el controlador de software
controlador del ncleo no est activado. la comprobacin de la temperatura tambin
se desactiva ya que esto desencadena la vigilancia de hardware en algunas tarjetas.

Funcin
Una vez iniciado organismo de control, que se pone en el fondo y luego trata de todos los
controles especificados en el archivo de configuracin a su vez. Entre cada dos pruebas ser
escribir en el dispositivo del ncleo para evitar un reinicio. Despus de terminar todas las
pruebas de vigilancia se va a dormir durante algn tiempo. Los controladores del ncleo
espera una escritura en el dispositivo de vigilancia cada minuto. De lo contrario se
reiniciar el sistema. Como organismo de control por defecto va a dormir por slo 10
segundos para que se dispara el dispositivo a tiempo.
En condiciones de alta carga del sistema de vigilancia podra ser intercambiado sin
memoria y puede dejar de hacerlo de nuevo en el tiempo. En estas circunstancias, el ncleo
de Linux se restablecer la mquina. Para asegurarse de que no se va a reinicios
innecesarios asegurarse de que tiene la variable de tiempo real se establece a yes en el
archivo de configuracin watchdog.conf. Esto aade soporte en tiempo real al organismo
de control: se bloquear en s en la memoria y no debe haber ningn problema, incluso en
el ms alto de cargas.
Tambin se puede especificar un mximo permitido de carga promedio. Una vez que se
alcanza este medio de carga se reinicia el sistema. Puede especificar promedios de carga
mximas durante 1 minuto, 5 minutos o 15 minutos. Los valores por defecto es desactivar
esta prueba. Tenga cuidado de no ajustar este parmetro demasiado bajo. Para establecer un
valor menor que el valor mnimo predefinido de 2, usted tiene que utilizar la opcin -f.
Tambin puede especificar una cantidad mnima de memoria virtual que desea tener
disponible como libre. Tan pronto como la accin ms memoria virtual se utiliza es tomado
por el regulador. Tenga en cuenta, sin embargo, que watchdog no distingue entre los
diferentes tipos de uso de la memoria. Slo chequea para la memoria virtual libre.
Si usted tiene una tarjeta de vigilancia con sensor de temperatura puede especificar la
temperatura mxima permitida. Una vez se alcanza esta temperatura se detiene el sistema.
El valor por defecto es 120. No hay una conversin de unidad, de modo que asegrese de
usar la misma unidad que su hardware. Organismo de control emitir advertencias vez que
la temperatura aumenta 90%, 95% y 98% de esta temperatura.

Cuando se utiliza el modo de archivo de vigilancia tratar de stat (2) los ficheros dados.
Los errores devueltos por stat no causarn un reinicio. Para un reinicio de la llamada stat
tiene que durar al menos un minuto. Esto puede suceder si el archivo se encuentra en un
sistema de archivos NFS montado. Si su sistema se basa en un sistema de archivos montado
en NFS puede probar esta opcin. Sin embargo, en tal caso, la opcin de sincronizacin
puede no funcionar si el servidor NFS no est respondiendo.
organismo de control puede leer el PID de un archivo pid y ver si todava existe el
proceso. Si no es as, la accin es tomada por el regulador. Por lo que puede, por ejemplo,
reiniciar el servidor de su reparacin en binario.
watchdog tratar peridicamente a la mesa en s para ver si la tabla de procesos est llena.
Este proceso dejar un proceso zombie hasta el organismo de control se despierta de nuevo
y lo atrapa; esto es inofensivo, no se preocupe por ello.
En el modo de vigilancia de ping intenta hacer ping a las direcciones IP includas. Estas
direcciones no tienen que ser una sola mquina. Es posible hacer ping a una direccin de
difusin lugar para ver si al menos una mquina en una subred sigue viviendo.
No utilice este ping emisin a menos que su persona un MIS) lo sabe y b) le ha dado
permiso explcito para utilizarlo!
organismo de control enviar tres paquetes de navegacin y espere hasta <intervalo>
segundos para la respuesta con <intervalo> es el tiempo que se va a dormir entre dos
tiempos de activacin del dispositivo de vigilancia. De este modo una red inalcanzable no
provocar un restablecimiento completo, pero un reinicio suave.
Tambin puede probar de forma pasiva para una red inalcanzable con slo el seguimiento
de una interfaz dada para el trfico. Si llega ningn trfico de la red se considera
inalcanzable causando un reinicio suave o una accin desde el binario de reparacin.
organismo de control puede ejecutar un comando externo para las pruebas definidas
por el usuario. Un cdigo de retorno es igual a 0 significa que se produjo un error y
organismo de control debe reaccionar. Si el comando externo muere por una seal no
capturada esto se considera un error por el organismo de control tambin. El comando
puede tomar ms tiempo que el perodo de tiempo definido para el dispositivo de ncleo sin
un problema. Sin embargo, los mensajes de error se generan en la instalacin syslog. Si ha
habilitado softboot por error de la mquina se reiniciar si el binario no sale en la mitad del
tiempo de vigilancia duerme entre dos intentos de activacin del dispositivo de ncleo.
Si especifica un binario de reparacin que se iniciar en lugar de apagar el sistema. Si este
binario no es capaz de solucionar el problema de vigilancia seguir siendo causar un
reinicio despus.

Si la mquina se detiene un correo electrnico se enva a notificar a un ser humano que la

mquina va a la baja. A partir de la versin 4.4 de vigilancia tambin notificar al ser
humano a su cargo si la mquina se reinicia.

Arranque blando
Un reinicio por software (es decir, el apagado controlado y reiniciar el sistema) se inicia por
cada error que se encontr. Ya que podra haber ms procesos disponibles, perro guardin
lo hace todo por s mismo. Eso significa:
1.
Matar a todos los procesos con SIGTERM.
2.
Despus de una breve pausa matar a todos los procesos restantes con SIGKILL.
3.
Registrar una entrada de parada en wtmp.
4.
Guardar la semilla aleatoria desde / dev / urandom. Si el dispositivo es inexistente o no hay
un nombre de archivo para guardar este paso se omite.
5.
Desactive la contabilidad.
6.
Desconectar todas las partes y de intercambio.
7.
Desmonte todas las particiones excepto la particin raz.
8.
Volver a montar la particin raz de slo lectura.
9.
Cierre todas las interfaces de red.

10.
Finalmente reiniciar.

Compruebe binario
Si el cdigo de retorno del binario de verificacin no es cero organismo de control
supondr un error y reinicie el sistema. Tenga cuidado con esto si est utilizando las
caractersticas de tiempo real de vigilancia desde el organismo de control esperar a que el
retorno de este binario antes de continuar. Un cdigo de salida positiva se interpreta como
un cdigo de error del sistema (consulte errno.h para ms detalles). Los valores negativos
son especiales para vigilancia:
-1
Reiniciar el sistema. Esto no es exactamente un mensaje de error, pero un comando de
perro guardin. Si el cdigo de retorno es -1 organismo de control no se intenta ejecutar
un script de cierre en su lugar.
-2
Restablecer el sistema. Esto no es exactamente un mensaje de error, pero un comando de
perro guardin. Si el cdigo de retorno es de -2 organismo de control simplemente se
niegan a escribir el nuevo dispositivo de kernel.
-3
promedio de carga mximo pasado.
-4
La temperatura en el interior es demasiado alta.
-5
/ proc / loadavg no contiene datos suficientes (o no).
-6
El archivo dado no fue cambiado en el intervalo dado.
-7
/ proc / meminfo contiene datos no vlidos.
-8

proceso hijo muri por una seal.

-9
proceso hijo no regres en el tiempo.
-10
Gratis para uso personal.

reparar binario
El binario de reparacin se inicia con un parmetro: el nmero de error que caus
organismo de control para iniciar el proceso de arranque. Despus de tratar de reparar el
sistema binario debera salir con 0 si el sistema fue reparado con xito y por lo tanto no hay
necesidad de arrancar ms. Un valor de retorno es igual a 0 indica que reiniciar el sistema
de vigilancia. El cdigo de retorno del binario de reparacin debe ser el nmero de error
del organismo de control de errores que causan para reiniciar. Tenga cuidado con esto si
est utilizando las caractersticas de tiempo real desde el organismo de control esperar a
que el retorno de este binario antes de continuar.

Directorio de prueba
Ejecutables colocados en el directorio de prueba son descubiertos por organismo de control
en el arranque y se ejecutan automticamente. Ellos estn limitadas en cuanto a tiempo por
la Instruccin de prueba-tiempo de espera en watchdog.conf.
Estos se llaman ejecutables, ya sea con "prueba" como primer argumento (si se est
realizando una prueba) o "reparar" como primer argumento (si se est realizando una
reparacin para una operacin que ha fallado previamente "prueba" en).
Los cdigos de salida como con programas de prueba y los binarios de reparacin, que se
espera para una operacin de prueba o reparacin exitosa es siempre cero.
Si la operacin de prueba de un ejecutable falla, el mismo ejecutable es llamado
automticamente con el argumento de "reparacin", as como el cdigo de retorno de la
operacin de prueba fallado previamente.
Por ejemplo, si la siguiente ejecucin vuelve 42:
prueba /etc/watchdog.d/my-test
El demonio guardin intentar reparar el problema llamando a:
reparacin /etc/watchdog.d/my-test 42

Esto permite a los administradores y desarrolladores de aplicaciones hacer comandos

inteligentes prueba / reparacin. Si no se requiere la operacin de "reparacin" (o no es
probable que tenga xito), es importante que el autor del comando devuelve un valor
distinto de cero para que la mquina todava se reiniciar como se esperaba.
Tenga en cuenta que el demonio guardin puede interpretar y actuar sobre cualquiera de los
cdigos de retorno reservados mencionados en la seccin binario Comprobar antes de
llamar a una orden dada en el modo de "reparacin".

Loco
Ninguno conocido hasta el momento.

autores
El cdigo original es un ejemplo escrito por Alan Cox < alan@lxorguk.ukuu.org.uk >, el
autor del controlador del ncleo. Todas las adiciones fueron escritas por Michael Meskes <
meskes@debian.org >. Johnie Ingram < johnie@netgod.net > tuvo la idea de poner a
prueba el promedio de carga. Tambin se hizo cargo de los trabajos especficos de Debian.
David Cinege < dcinege@psychosis.com > plante algunos problemas de vigilancia de
hardware y ayud a probar estas cosas.

archivos
/ dev / guardin
El dispositivo de vigilancia.
/var/run/watchdog.pid
El archivo pid del organismo de control en ejecucin.

Ver tambin
CMO de Watchdog Uso Linux
Archivado en: ARM9 , incrustado en Linux - Etiquetas: ARM9 , incrustado en Linux kunilkuda @ 16:08
Si eres nuevo con Linux embebido, uno de lo interesante que puede empezar a aprender es
cmo utilizar el organismo de control.
Organismo de control, al igual que su nombre, es un tipo de perifrico que va a arrancar el
sistema si no se 'alimenta' en un momento determinado (En nuestros trminos diarias: se va
a morder su sistema, a menos que golpeara con el pie). Por lo tanto, se evitar que el

sistema se cuelgue. Es una buena caracterstica a tener, especialmente si no hay nadie

alrededor para presionar el botn 'reset' para ti =)
conductor de vigilancia
Para utilizar perifrica de vigilancia en Linux, se necesita:
1. Watchdog conductor: La mayora de los proveedores de mesa le proporcionar de
forma gratuita (pida su apoyo si es necesario). En este artculo se est utilizando
controlador de vigilancia proporcionado EA3131 Linux BSP.
2. archivo de dispositivo de vigilancia: Archivo de dispositivo es un tipo especial de
archivo para marcar el nodo de dispositivo en su sistema de ficheros raz (para que
pueda acceder a los perifricos como el acceso a archivo .. "todo es un archivo 'en el
sistema UNIX). Normalmente se llama "/ dev / perro guardin"
Si usted no tiene archivo de dispositivo de vigilancia en su sistema de ficheros raz de
destino, puede volver a crearlo usando 'mknod'
1 # mknod /dev/watchdog c 10 130
Of course, the mknod tool must be present in your root filesystem first before you can
execute this. To run the watchdog driver in your system
1 # insmod your_watchdog_driver.ko
Starting Stopping Watchdog
The watchdog is automatically started once you open /dev/watchdog. To stop the
watchdog, you will need to:
1. Write character V into /dev/watchdog to prevent stopping the watchdog
accidentally
2. Close the /dev/watchdog file
An exception on stopping the watchdog by closing the file is when
CONFIG_WATCHDOG_NOWAYOUT is enabled in your kernel configuration. When
this option is enabled, the watchdog cannot be stopped at all. Hence, you will need to feed /
kick it all the time or it will reset the system
Kicking Watchdog
To kick or to feed the watchdog you can do it in two ways:

1. Write any character into /dev/watchdog. You can write any character into
/dev/watchdog, but, my suggestion, dont write V character (See the StartingStopping Watchdog point above)
2. Use IOCTL to insert WDIOC_KEEPALIVE value.
Other Things To Do with Watchdog
If youre bored with the standard start-kick-stop things, you can also try out other watchdog
features:

Set the watchdog timeout. Use IOCTL with WDIOC_SETTIMEOUT

Get the current watchdog timeout. Use IOCTL with WDIOC_GETTIMEOUT

Check if the last boot is caused by watchdog or it is power-on-reset. Use IOCTL

with WDIOC_GETBOOTSTATUS.

If you are interested to know more about using watchdog in Linux, read the watchdog
documentation in Linux source code (Linux-x.y.z/Documentation/watchdog/watchdogapi.txt). Heres some demo code to test the Linux watchdog:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

/*
* Linux watchdog demo for LPC313x
*
* This program is free software; you can redistribute it and/or
modify
* it under the terms of the GNU General Public License as published
by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 021111307 USA
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <getopt.h>
#include <string.h>
#include <errno.h>

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

#include <linux/watchdog.h>
#define WATCHDOGDEV "/dev/watchdog"
static const char *const short_options = "hd:i:";
static const struct option long_options[] = {
{"help", 0, NULL, 'h'},
{"dev", 1, NULL, 'd'},
{"interval", 1, NULL, 'i'},
{NULL, 0, NULL, 0},
};
static void print_usage(FILE * stream, char *app_name, int exit_code)
{
fprintf(stream, "Usage: %s [options]\n", app_name);
fprintf(stream,
" -h --help
Display this usage information.\n"
" -d --dev <device_file>
Use <device_file> as watchdog device
file.\n"
"
The default device file is
'/dev/watchdog'\n"
" -i --interval <interval> Change the watchdog interval
time\n");
exit(exit_code);
}
int main(int argc, char **argv)
{
int fd;
/* File handler for watchdog */
int interval;
/* Watchdog timeout interval (in secs) */
int bootstatus;
/* Wathdog last boot status */
char *dev;
/* Watchdog default device file */
int next_option;
/* getopt iteration var */
char kick_watchdog;
/* kick_watchdog options */
/* Init variables */
dev = WATCHDOGDEV;
interval = 0;
kick_watchdog = 0;
/* Parse options if any */
do {
next_option = getopt_long(argc, argv, short_options,
long_options, NULL);
switch (next_option) {
case 'h':
print_usage(stdout, argv[0], EXIT_SUCCESS);
case 'd':
dev = optarg;
break;
case 'i':
interval = atoi(optarg);
break;

case '?':
/* Invalid options */
72
print_usage(stderr, argv[0], EXIT_FAILURE);
73
case -1:
/* Done with options */
74
break;
75
default:
/* Unexpected stuffs */
abort();
76
}
77
} while (next_option != -1);
78
79
/* Once the watchdog device file is open, the watchdog will be
80 activated by
81
the driver */
fd
= open(dev, O_RDWR);
82
if
(-1
== fd) {
83
fprintf(stderr, "Error: %s\n", strerror(errno));
84
exit(EXIT_FAILURE);
85
}
86
/* If user wants to change the watchdog interval */
87
if (interval != 0) {
88
fprintf(stdout, "Set watchdog interval to %d\n", interval);
89
if (ioctl(fd, WDIOC_SETTIMEOUT, &interval) != 0) {
90
fprintf(stderr,
91
"Error: Set watchdog interval failed\n");
exit(EXIT_FAILURE);
92
}
93
}
94
95
/* Display current watchdog interval */
96
if (ioctl(fd, WDIOC_GETTIMEOUT, &interval) == 0) {
97
fprintf(stdout, "Current watchdog interval is %d\n", interval);
}
else
{
98
fprintf(stderr,
"Error: Cannot read watchdog interval\n");
99
exit(EXIT_FAILURE);
10
}
0
10
/* Check if last boot is caused by watchdog */
if (ioctl(fd, WDIOC_GETBOOTSTATUS, &bootstatus) == 0) {
1
fprintf(stdout, "Last boot is caused by : %s\n",
10
(bootstatus != 0) ? "Watchdog" : "Power-On-Reset");
2
} else {
10
fprintf(stderr, "Error: Cannot read watchdog status\n");
3
exit(EXIT_FAILURE);
}
10
4
/* There are two ways to kick the watchdog:
10
- by writing any dummy value into watchdog device file, or
5
- by using IOCTL WDIOC_KEEPALIVE
10
*/
fprintf(stdout,
6
"Use:\n"
10
" <w> to kick through writing over device file\n"
7
" <i> to kick through IOCTL\n" " <x> to exit the program\n");
10
do {
8
kick_watchdog = getchar();
switch (kick_watchdog) {
10

case 'w':
9
write(fd, "w", 1);
110
fprintf(stdout,
111
"Kick watchdog through writing over device file\n");
112
break;
case 'i':
113
ioctl(fd, WDIOC_KEEPALIVE, NULL);
114
fprintf(stdout, "Kick watchdog through IOCTL\n");
115
break;
116
case 'x':
117
fprintf(stdout, "Goodbye !\n");
break;
118
default:
119
fprintf(stdout, "Unknown command\n");
12
break;
0
}
} while (kick_watchdog != 'x');
12
1
/* The 'V' value needs to be written into watchdog device file to
12
indicate
2
that we intend to close/stop the watchdog. Otherwise, debug
12 message
3
'Watchdog timer closed unexpectedly' will be printed
*/
12
write(fd, "V", 1);
4
/* Closing the watchdog device will deactivate the watchdog. */
12
close(fd);
5 }
12
6
12
7
12
8
12
9
13
0
13
1
13
2
13
3
13
4
13
5
13
6
13
7

13
8
13
9
14
0
14
1
14
2
14
3
14
4
14
5
14
6
14
7
14
8
14
9
15
0
15
1
15
2
15
3
15
4
15
5
15
6
15
7
15
8
15
9
Note1: The watchdog driver may not implement all of IOCTL that is used in this demo
code

Note2: The demo is tested on LPC313x (on EA3131 board). See LPCLinux forum for the
details.
Note3: Assuming youre using CodeSourcerys GNU/Linux , the command to compile it
for ARM926EJ-S is
$ arm-none-linux-gnueabi-gcc -mcpu=arm926ej-s watchdog_demo.c -o

1watchdog_demo

*-*********************************************************************

Implementando un watchdog de emergencia

Fotografa de Jeff Mayzurk

Un watchdog es, como su nombre indica, un perro guardian ;), que en general se encarga de
monitorizar un aspecto del sistema para llevar a cabo una accin cuando algo falla. Alguna
vez he puesto uno por aqu.
Bueno, es una definicin un poco de estar por casa, como lo que voy a explicar ahora:
cmo hacer un sencillo watchdog para un servicio, con un shell y herramientas comunes
en cualquier entorno Unix.
Ayer un compaero me pidi que le echara una mano con el servidor de un ex-cliente, y
como cada vez se puede dedicar menos tiempo a mantener esa mquina, decidimos poner
un watchdog para un servicio que haba dado problemas ocasionalmente pero no podamos
diagnosticar y corregir.
Vamos a suponer un caso bastante frecuente, en el que el servicio es un solo proceso, que
adems guarda su PID en un fichero.
Nuestro watchdog hara lo siguiente:
1. Comprobar que el fichero PID existe: sino existe, eso es seguramente
seal de que el servicio est parado.
2. Verificar que el proceso indicado por ese PID, efectivamente est
funcionando: sino encontramos el proceso, suponemos que el servicio ha

terminado de forma imprevista (y no ha borrado el fichero, como es

habitual).
3. Si se cumple cualquiera de los puntos anteriores, lanzamos el servicio
(borrando el fichero del PID en caso de ser necesario, para evitar que el
servicio piense que ya est en marcha).

Es un watchdog muy rudimentario que correramos desde cron(8) con la frecuencia que
creamos conveniente.
Ms o menos la implementacin que hice ayer fue la siguiente, un poco revisada para
publicarlo aqu (claro :D):
#!/bin/sh
# configurable
PIDFILE="/var/run/bogom/bogom.pid"
DAEMON="/usr/local/libexec/bogom"
MAILTO=administrador
# Arranca el servicio y manda un mail al admin
up_and_notice()
{
$DAEMON
echo "He arrancado $DAEMON (resultado $?), un saludo :)" \
| mail -s "$0 en `hostname`" $MAILTO
}
# existe el fichero con el PID?
if [ ! -f $PIDFILE ]; then
up_and_notice
exit 0
fi
PID=`cat $PIDFILE 2> /dev/null`
# hay efectivamente un PID?
if [ "X" == "X$PID" ]; then
up_and_notice
exit 0
fi
ps -p $PID 2> /dev/null 1> /dev/null
# existe el proceso con ese PID?
if [ $? -ne 0 ]; then
# si no existe, el fichero sobra
rm $PIDFILE

fi
# EOF

up_and_notice
exit 0

En el ejemplo he usado el servicio de bogom (no porque lo necesite, ojo :D), y como bonus
se enva un correo al administrador para informar de que se ha levantado otra vez el
proceso.
En este caso el watchdog lo tiene que correr root, as que aadiramos el script en el
crontab(5) de ese usuario. Sera muy raro que funcionara tal cual para otros casos, pero
como es muy sencillo, seguro que resulta fcil de adaptar.
No me gustan mucho los watchdogs, pero es bueno asumir que todos los programas tienen
fallos y a veces causan problemas, y no siempre hay un administrador para ver qu est
pasando. En la mayora de las veces el fallo es anecdtico, y con volver a arrancar:
solucionado ;).