Cuelgue esporádico con VDR-NG-EM 0.4 build 461 (unstable) (linux build)

Muchas gracias.

Mirándolo por encima tiene muy buena pinta. Mañana lo probaré.

Hay una cosa que no entiendo, aunque supongo que será por mi desconocimiento del funcionamiento interno del firmware: ¿por qué sólo inicias el vdr si existe el fichero /etc/rc.local.conf? Y ya puestos, ¿por qué es necesario ejecutar ese archivo antes de cada reinicio?

garbas escribió:Muchas gracias.

Mirándolo por encima tiene muy buena pinta. Mañana lo probaré.

Hay una cosa que no entiendo, aunque supongo que será por mi desconocimiento del funcionamiento interno del firmware: ¿por qué sólo inicias el vdr si existe el fichero /etc/rc.local.conf? Y ya puestos, ¿por qué es necesario ejecutar ese archivo antes de cada reinicio?

Hola garbas,

En el fichero /etc/rc.local.conf se crean las variables necesarias para iniciar el VDR, como son ${runvdr_vars} y ${runvdr}, por eso se interpreta ese fichero antes de lanzar el VDR.

Y respecto a ejecutar este fichero en cada reinicio es porque así, al arrancar se instala en el cron, de manera que se ejecuta cada minuto y comprueba si el VDR se ha muerto, y en caso de que así sea lo rearranca con las opciones apropiadas.

No es necesario hacerlo siempre así, de hecho, se puede quitar del arranque y ejecutarlo a mano en cualquier momento, pro ejemplo, despuñes de un cuelgue. Eso sí, una vez que lo ejecutas, ya sea en el arranque o mano, ya queda instalado en el cron y comprobando el proceso VDR cada minuto.

Si ya estás usando el cron para algo no sería buena idea ejecutarlo, ya que actualmente borra todo lo que haya en el cron, aunque supongo que la mayoría de nosotros no lo usamos, de todos modos.

Si tienes cualquier duda, pregunta, intentaré responderte más rápido la próxima vez. Se me había pasado este mensaje.

Saludos,
Solrac

Muchas gracias por la aclaración.
Sólo una cosa: cuando decía "este archivo" me refería al rc.local.conf.

Se supone que ese archivo se carga en el arranque (de hecho, lo carga el mismo rc.local al que se añade la carga del restart_vdr_when_killed.sh), luego esas variables ya deberían estar en el entorno. Supongo que cargarlo cada vez es una medida de precaución.

Por otro lado, ya había visto que el script se merienda las "tareas programadas" que pudiera tener el usuario root. A la mayoría no nos afectará, pero es algo a tener en cuenta a la hora de utilizar el script.

Y no tienes que disculparte por la "velocidad" de tus respuestas, ¡faltaría más!
Todos tenemos nuestras responsabilidades y responder en un foro donde participamos de forma voluntaria y desinteresada no es ni mucho menos lo más prioritario.

Así que muchas gracias de nuevo por el script y por tus explicaciones.
En cuanto consiga encontrar un hueco lo probaré, que aún no he podido y eso que ya he pasado por todos los "cuelgues" que se mencionan en el foro (y alguno más).

garbas escribió:Se supone que ese archivo se carga en el arranque (de hecho, lo carga el mismo rc.local al que se añade la carga del restart_vdr_when_killed.sh), luego esas variables ya deberían estar en el entorno. Supongo que cargarlo cada vez es una medida de precaución.

Ah! Ok. Es una buena pregunta. Lo hago así porque el script está pensado para poder lanzarlo a mano, y no solo desde el rc.local.

De hecho, lo escribí para lanzarlo por telnet en el caso de que se colgase el VDR y ya, de paso, le puse que se quedase residente.

Saludos,
Solrac

Aquí os dejo otro script más sencillo de homerlinux.

homerlinux escribió:Ahí va el chapuza-script (a copiar en /etc, funciona perfecto). Notas:
1) en "/etc/rc.local" poner /bin/ash /etc/watchdog &
(justo despues de la primera linea, #!/bin/ash). El ampersand "&" es imprescindible para no jorobar el arranque y posiblemente bloquear todo.
2) el primer sleep es para dar a entrar tiempo a toda pastilla por telnet/ssh si algo va mal y matar el watchdog.
3) el segundo sleep es el interbalo de comprobacion. A mi me sobra con 60 segundos.

saludos:

Código:



#!/bin/ash
#/etc/watchdog

sleep 60

while true
do
sleep 60
N=`ps | grep /usr/bin/vdr | grep -v grep | wc -l`
if [ $N -gt 0 ]
then
echo VDR corriendo OK...
else
echo VDR muerto...lanzando VDR...
/usr/bin/logger VDR muerto...lanzando VDR...
/usr/bin/start-vdr
fi
done



Este último script tiene la ventaja de no usar crond. Si el firmware no lo arranca por defecto, supongo que este script consumirá algo menos de recursos que el otro (siempre hablando con un consumo realmente bajo en ambos casos).

Cada vez hay más opciones para mitigar el problema de los "cuelgues".

Además, zjuanma ha subido al repositorio una aplicación para reiniciar el VDR o todo el Giga mediante combinaciones de botones del mando.

Y yo sin apenas tiempo para probar cosas...

Bueno, pues tras ocurrir el infalibre cuelgue diario, el exit code del proceso /usr/bin/vdr ha sido "143".

En los trozos de código que me ha dado tiempo a mirar, solamente se termina VDR (en vdr.c) con códigos 0, 1 y 2 (es decir, lo normal en *IX).

Así que puede ser:

-Un exit dislocado (por cierto, a veces se sale con exit() y otras con la macro EXIT()) desde cualquier función (caramba, hay unas cuantas...)

-Un return desde el mainloop con ese argumento, o sin ningún argumento en absoluto (y que según esté el stack devuelva eso, de chiripa).


No me ha dado tiempo a mirar mucho, seguiré investigando.

¿alguna idea? ¿alguien más ha mirado el exit code de vdr?

Saludos

homerlinux escribió:Bueno, pues tras ocurrir el infalibre cuelgue diario, el exit code del proceso /usr/bin/vdr ha sido "143".

En los trozos de código que me ha dado tiempo a mirar, solamente se termina VDR (en vdr.c) con códigos 0, 1 y 2 (es decir, lo normal en *IX).

De hecho esos tres códigos de salida son los únicos documentados en la página man de vdr:

Código:

EXIT STATUS
      0      Successful program execution.

      1      An error has been detected which requires the DVB driver and vdr
              to be reloaded.

      2      An non-recoverable error has been detected, vdr has given up.


Es algún parche o modificación de nuestra Edición Mejorada, porque los alemanes tienen esos códigos de salida correctos pero nosotros no.

Parece que usa el pid del proceso como código de salida.

No sé si tendrá algo que ver, pero en la función SignalHandler del vdr.c los alemanes comentaron la primera línea y me suena que lo hicieron por los códigos de salida

Código:

static void SignalHandler(int signum)
{
// DON'T EVER DO THIS OR YOU END UP WITH A SIGHANDLER RACE
//  isyslog("caught signal %d", signum);
  switch (signum) {
   case SIGPIPE:
         break;
   case SIGHUP:
         LastSignal = signum;
         break;
   default:
         LastSignal = signum;
         Interface->Interrupt();
         ShutdownHandler.Exit(0);
   }
  signal(signum, SignalHandler);
}

Parece que usa el pid del proceso como código de salida.

Creo que no es eso, el codigo si no es un codigo devuelto por el proceso tiene que ser el código de la señal que motivo que el proceso acabase y no el PID.
A ver si encuentro en google un link que lo expliquen y lo pongo.

Editado: Aqui lo explican http://ry.ca/blog/2008/11/function_versus_exit/

homerlinux escribió:Bueno, pues tras ocurrir el infalibre cuelgue diario, el exit code del proceso /usr/bin/vdr ha sido "143".

Tras 10 cuelgues registrados en los logs en 4 dias, 9 de ellos han sido con el exit code=143, y solo uno de ellos con el exit code=138.

No tengo ningún proceso con esos PIDs. Ahora mismo tengo (extracto):

Código:


  77 root      1120 S    lircd --device=/dev/lirc
  79 root      1764 S    /bin/ash /etc/watchdog.MA
  85 root      1772 S    ash /etc/vdr/runvdr
  88 root      1772 S    inetd /etc/inetd.conf
  93 root      1744 S    /usr/sbin/webifd
  95 root      1764 S    /sbin/getty 115200 ttyS0
  96 root      1020 S    /usr/sbin/spindown -d 100 +/dev/sda
  97 root      1744 S    /usr/sbin/webifd
  145 root      1744 S    /usr/sbin/webifd
  291 root    57044 S    /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
  292 root    57044 S    /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
  294 root    57044 S    /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
  295 root    57044 S N  /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
  296 root    57044 S    /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
  297 root    57044 S N  /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
  298 root    57044 S N  /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
  299 root    57044 S    /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
  300 root    57044 S    /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
  301 root    57044 S    /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
  326 root    57044 S N  /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
 1338 root    57044 S    /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
 1965 root    57044 S    /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
 1966 root    57044 S    /usr/bin/vdr -E /var/vdr/epg.data -c /etc/vdr -L /var/vdr/lib -v /var/vdr/video0 -s /etc/vdr/shutdownvdr -Pepgsearc
 2064 root      1652 S    dropbear -i


Probablemente en otro reinicio no saldrían los PIDs iguales, aunque supongo que si parecidos. Lo unico que normalmente tengo cerca del 138-143 es webifd, que supongo será la interfaz web.

Asi que al pronto no parece que este exit code sea un PID...

¿alguna idea?

Saludos

Lee el post anterior, ya he comentado que ese numero no es un PID es un numero de señal + 128, el 143 es un SIGTERM (15) y el 138 un SIGKILL. (9)

¿Se ha averiguado algo? La cosa es que desde la última vez que posteé que se me había colgado... no me ha vuelto a pasar (y hace muchos días ya de eso...)

cascaman escribió:¿Se ha averiguado algo? La cosa es que desde la
última vez que posteé que se me había colgado... no me ha vuelto a
pasar (y hace muchos días ya de eso...)

Pues seguimos igual. Hoy un cuelgue con exit=137, y ayer dos cuelgues con exit=143 (por suerte el guardián que posteé hace que casi ni me entere).

En el cuelgue de esta mañana no había nadie en casa, así que ha sido el solito, sin manipular nada.

No he tenido mucho tiempo para investigar con los examenes...

Creo que zjuanma tiene razón en su mensaje anterior, estos dos exit codes pueden producirse cuando el VDR recibe SIGTERM o SIGKILL, los valores coinciden con lo que dice. Ignoro si en el código hay un handler que se pueda modificar para obtener más información: falta saber por qué narices y qué proceso manda esas señales al VDR.

En el caso de exit=138, que también lo he visto alguna vez, se corresponde con SIGBUS (bad memory access). Se supone que viene del propio núcleo.

Voy a cargar el mismo software en mi 2º gigaset, para descartar posible fallo de hardware.

Cualquier sugerencia es bienvenida.

Saludos

Rescato este hilo simplemente para comentar que me ha surgido un pequeño problemilla que creo que se debe a que estoy utilizando el script de homerlinux (https://vdr-m7x0.foroactivo.com.es/problemas-encontrados-f5/cuelgue-esporadico-con-vdr-ng-em-04-build-461-unstable-linux-build-t467-15.htm#6796).

Cuando, al arrancar, se lanza la comprobación del disco, el VDR se inicia antes de que finalice dicha comprobación.
Creo que se debe a que lo lanza el script watchdog, que se ejecuta en el rc.local antes que el usbautomounter (que supongo que será el que lanza la comprobación de los discos).

Me parece que lo más correcto sería lanzar la ejecución del watchdog después (o en lugar de) la ejecución de ash ${runvdr} &, que es el momento en el que ya se puede ejecutar el VDR.

De momento yo lo he cambiado así. La próxima vez que se compruebe algún disco veré si funciona correctamente.

bittor escribió:Es algún parche o modificación de nuestra Edición Mejorada, porque los alemanes tienen esos códigos de salida correctos pero nosotros no.

He investigado el tema y he encontrado diversos errores:
- En algún caso, al cerrar vdr los eventos se destruían después de finalizar la ejecución. Esto producía una salida con código SIGSEGV (139). He subido un parche para solventarlo.
- Tanto rebootvdr como kill-vdr mandan la señal SIGTERM al vdr cada cierto tiempo. La primera vez, VDR captura la señal y empieza un cierre ordenado (código de salida cero). Si mientras está cerrando recibe otro SIGTERM, ya no está capturado y cierra a capón con código SIGTERM (143). Por eso no nos funcionan los códigos de los alemanes. kill-vdr, rebootvdr y rc.halt.local deberían enviar una sola vez SIGTERM y pasado un tiempo prudencial, SIGKILL.
- El código SIGKILL (137) nunca debería reiniciar el VDR en runvdr, si alguien se pone duro para que salgamos (KILL), debemos salir.
- Con el resto de códigos de salida debemos reiniciar, excepto con el 0 y el 2 (como dicen los alemanes)

Esto implica modificar kill-vdr, rebootvdr y rc.halt.local.

¿Que opináis?

Tío, eres un máquina.


Como ya habrás visto, en nuestra versión se envían los SIGTERM cada 5 segundos durante 20 segundos y después el SIGKILL.
En la versión alemana los SIGTERM son cada 30 segundos durante 5 minutos y no hay un SIGKILL.

Esto lo cambiamos al principio creo recordar por algún problema con el parche de shutdown que alguna vez se pegaba 5 minutos hasta que se apagaba y encima se perdía la EPG al no haberse cerrado el VDR, así siempre como máximo sólo esperábamos 20 segundos y se guardaba la EPG.

Entiendo que con el nuevo parche que has subido ya podemos poner todos estos parámetros igual que los alemanes y los códigos de salida coincidirán ¿no?.

El parche que he subido solo corrige un error al cerrar vdr evitando en algún caso una salida con 139.
Los alemanes al esperar 30 segundos entre cada SIGTERM no suelen ver el problema. VDR normalmente cierra antes de los 30 segundos. Pero si tardase más les pasaría lo que a nosotros, código de salida 143.
Además no tienen en cuenta que un SIGKILL (código de salida 137) no debe reiniciar el VDR.

Estoy estudiando anular los sucesivos SIGTERM dentro del propio VDR hasta el cierre. Además de tratar adecuadamente el SIGKILL en el VDR. Dejadme que lo asegure un poco más.

¿A qué parche de shutdown te refieres? ¿se puede ver?

El problema con el parche de shutdown fue hace mucho tiempo cuando salió la primera versión VDR-NG y con un ToolChain bastante viejo.
Ahora ese parche ya lo han integrado los alemanes en el VDR-M7x0 y ya no está ese problema con el apagado, pero tal y como decías si en 30 segundos no se cierra el VDR tendrán el mismo problema que nosotros.

Creo que he llegado a una conclusión "decente" y la he subido como revisión 524.

Aquellos que tenéis un watchdog creo que deberíais desactivarlo ya que vdr se reiniciará solo ante cualquier crash. O al menos eso he intentado.

He ajustado también el commands.conf ya que vdr no puede esperar a ningún comando que implique el cierre del propio vdr. Se autobloquea, no cierra ordenadamente y al final se recurre a un kill.

Aquellos que miráis el log debéis ver líneas que yo no conocía como esta:

Código:

Mar 25 22:32:47 m740av user.info vdr: [268] exiting, exit code 0

Esta línea es la última que saca VDR antes de cerrar si todo ha ido bien.

Posix escribió:Creo que he llegado a una conclusión "decente" y la he subido como revisión 524.

Aquellos
que tenéis un watchdog creo que deberíais desactivarlo ya que vdr se
reiniciará solo ante cualquier crash. O al menos eso he intentado.

He
ajustado también el commands.conf ya que vdr no puede esperar a ningún
comando que implique el cierre del propio vdr. Se autobloquea, no
cierra ordenadamente y al final se recurre a un kill.

Aquellos
que miráis el log debéis ver líneas que yo no conocía como
esta:

Código:

Mar 25 22:32:47 m740av user.info vdr: [268] exiting, exit
code 0

Esta línea es la última que saca VDR antes de cerrar si
todo ha ido bien.

No se cuando la podré instalar, pero ya la estoy compilando, eres un fiera Posix.

A ver si los que tenían esos cuelgues pueden instalarse también esta revisión y nos sorprenden con sus noticias.

Salu2
jb

Fantástico trabajo Posix.

Yo tenía esos cuelgues. He instalado esa versión y por ahora ni uno

Gracias, Posix.

Posix escribió:Creo que he llegado a una conclusión "decente" y la he subido como revisión 524.

Instalada y probando a fondo. De momento perfecto, (ya había conseguido forzar el cuelgue a voluntad, y la no me pasa). Vista la explicación que has dado y como funciona ahora, creo que no es prematuro pensar que has dado en el clavo.

Felicidades y gracias.

Y yo confirmo que hasta día de hoy no he tenido ni un solo cuelgue.

Buen trabajo y gracias. :ok2:

homerlinux escribió:

Posix escribió:Creo que he llegado a una conclusión "decente" y la he subido como revisión 524.

Instalada y probando a fondo. De momento perfecto, (ya había conseguido forzar el cuelgue a voluntad, y la no me pasa). Vista la explicación que has dado y como funciona ahora, creo que no es prematuro pensar que has dado en el clavo.

Felicidades y gracias.