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

Jose Manuel de Arce jose.de.arce en gmail.com
Lun Ene 12 02:03:25 PST 2009


Hola

Gracias, la explicación es lógica y me encaja con lo que pasa. Es el
carácter "sticky" que yo comentaba y que tu has ilustrado
perfectamente.

El PC donde corre esto es un viejo Medion de MediaMarkt del año 2001
que aunque pasa el test de memoria, me ha dado multitud de problemas
que solo se explican por un HW defectuoso.

Buscaré si hay forma de hacer que el binario no se quede en la buffer cache.

     Gracias

     Josema

El día 11 de enero de 2009 22:38, pancho horrillo <pancho en pancho.name> escribió:
> 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(R), 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 en 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAklqZukACgkQ64HQYZTzLDlJ2wCfTEIQxr2E0pDY8VeIsma3x5qO
> q9UAoIDf+olmRouaITptvz5HoDE84Xa7
> =SdJH
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Madrid-pm mailing list
> Madrid-pm en pm.org
> http://mail.pm.org/mailman/listinfo/madrid-pm
>


Más información sobre la lista de distribución Madrid-pm