[Madrid-pm] Feliz año nuevo, y una cuestion

[pancho horrillo]

On Thu, Jan 08, 2009 at 10:42:30AM +0100, Jose Manuel de Arce wrote:
> Estimados,
> 
Saludos, terrícola!

> lo primero, felicitar el año nuevo a todos.
> 
Feliz ciclo solar.

> Ahora me animo a describir una situación por si alguien ha tenido una
> experiencia parecida.
> 
> En linux, slackware, una serie de scripts (en perl, claro) que leen
> correo por pop3 y procesan los mensajes se invocan por cron cada
> cierto tiempo (5 minutos). Graban algunos ficheros en disco y ya. Esto
> funciona desde principios de Diciembre, y al cabo de un tiempo
> variable, desde 10 días hasta 2 días, el binario perl ya no funciona,
> cualquier invocacion se salda con un "Segmentation Fault".
> 
> desde el shell, haciendo perl -v, segmentation fault. El resto de
> procesos funciona sin problema y se pueden lanzar otros binarios.
> 
Recreación del delito:

0. system boot.

1. crond arranca, y ejecuta un script perl, que fuerza la carga de su
intérprete, /usr/bin/perl.  Como buen hijo de UNIX®, linux lee el
binario del disco y lo carga en el buffer caché.

2. linux crea un proceso perl a partir de la imagen recién cargada en el
buffer caché.

3. El script finaliza, el proceso se muere, un funeral austero, etc.

4. crond sigue invocando al script cada 5 minutos, repitiéndose la
creación del proceso perl a partir de la imagen almacenada en el buffer
caché.  Es decir, la imagen /usr/bin/perl no se vuelve a leer del disco.
So far so good.

5. En algún momento, debido a un bug de linux o tal vez memoria RAM
defectuosa, la imagen de /usr/bin/perl en el buffer caché se corrompe un
pelín.

6. Las subsiguientes invocaciones al binario perl acaban ejecutando
dicha imagen corrupta, concluyendo en una desreferencia de NULL (0), lo
que hace que el linux se enfurezca y le envíe una señal fulminante, como
caída del cielo.


Si esto es lo que pasa, recomiendo hacer una copia a priori del binario
/usr/bin/perl en otra parte, digamos /usr/local/bin/perl.  Cuando se
alcanza el estado del paso #5, probar a ver si la copia (que aún no está
en el buffer caché), se ejecuta.  A simple /usr/local/bin/perl -v will
suffice.

Esta condición podría ser debida a un fallo de la RAM.  ¿La máquina
tiene memoria ECC?  Si no, antes o despues algún bit se invierte, y la
información contenida se corrompe.  Una pasadita de memtest86+ no
vendría mal, at any rate, por si hay bits que fallen de forma
sistemática.

La versión de la slackware, perl, el linux, así como el .config de éste
podrían venir bien para saber a qué nos enfrentamos.  Quizá el fallo
esté en el kernel.

Hope that it helps.

Un saludo,

pancho.

> un strace, que es lo que he sabido hacer, (strace perl -v) termina con:
> .
> .
> .
> mmap2(NULL, 178476, PROT_READ, MAP_PRIVATE, 3, 0) = 0x401d3000
> close(3)                                = 0
> open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 3
> read(3, "\t\234\224\246", 4)            = 4
> close(3)                                = 0
> time([1231407045])                      = 1231407045
> mmap2(NULL, 135462912, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401ff000
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> 
> Y no tengo otra forma de recuperar la situacion que rebotando.
> 
> Parece que algo queda en memoria, sticky, entre invocaciones. los
> scripts terminan con normalidad hasta que dejan de hacerlo, y ya no se
> puede usar perl.
> 
> Parece que el uso repetido,, via cron, y la invocacion muchas veces,
> dejara algo en memoria, o en cache, o no sé dónde, que no puedo
> vaciar, y provoca lo que describo.
> 
> Alguna pista de como evitar esto o como corregir esta situacion sin rebotar?
> 
>   Gracias
> 
>   josema
> _______________________________________________
> Madrid-pm mailing list
> Madrid-pm at pm.org
> http://mail.pm.org/mailman/listinfo/madrid-pm

-- 
pancho horrillo

To be conscious that
you are ignorant is a great step
to knowledge.

		Benjamin Disraeli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mail.pm.org/pipermail/madrid-pm/attachments/20090111/4ccf4e95/attachment.bin>