2010-02-21 11 views
7

Mi Perl web-app, que corre bajo mod_fastcgi Apache, con frecuencia recibe errores como el siguiente:¿Qué significa "Recuento máximo de señales pendientes (120) excedidas"?

recuento máxima de señales pendientes (120) superó en la línea 119.

que he visto esto sucede en relación con las cargas de archivos, pero no estoy seguro de que sea la única vez que sucede. También obtengo un SIGPIPE justo antes (o posiblemente después) de ese error.

¿Alguna idea?

EDIT Gracias por las sugerencias de todos. Alguien preguntó qué línea era 119. Lo siento, debería haberlo puesto. Está en un bloque de código donde ejecuto el verificador de virus en un archivo cargado. No obtengo el error todas las veces, solo ocasionalmente.

if(open VIRUS_CK, '|/usr/local/bin/clamscan - --no-summary >'.$tmp_file) { 

    print VIRUS_CK $data; // THIS IS LINE 119 

    close VIRUS_CK; 

    if (($? >> 8) == 1) { 

    open VIRUS_OUTPUT, '<'.$tmp_file; 
    my $vout = <VIRUS_OUTPUT>; 
    close VIRUS_OUTPUT; 
    $vout =~ s/^stdin:\s//; 
    $vout =~ s/FOUND$//; 


    print STDERR "virus found on upload: $vout\n"; 
    return undef, 'could not accept attachment, virus found: '.$vout; 
    } 
    unlink($tmp_file); 
} 
+0

pregunta obvia: ¿qué es la línea 119? – ysth

+0

cuando perl se queja así, ¿sale, o simplemente pierde esas señales? – mcr

Respuesta

7

Esto significa que el sistema operativo está entregando señales a Perl más rápido de lo que puede manejar, y se ha alcanzado el punto de saturación. Entre las operaciones, Perl guarda las señales que se manejarán y luego las maneja una vez que tiene una oportunidad. Obtiene este error porque recibió demasiadas señales antes de que Perl tuviera la oportunidad de recuperar el aliento. Este es un error fatal, por lo que su proceso Perl termina.

La solución es averiguar qué está generando tantas señales. Consulte here para obtener más información.


Actualización: Mi respuesta original era algo inexacto, diciendo que la generación de un nuevo proceso de Perl fue parte de la cuestión, cuando en realidad no lo era. He actualizado según el comentario de @ysth a continuación.

+1

nada que ver con comenzar un nuevo proceso; perl captura señales y las guarda para enviarlas a un punto seguro entre operaciones, y este error indica que se recibieron muchas señales antes de ese punto de seguridad. – ysth

+0

¿Tiene alguna idea sobre cómo saber de dónde viene la señal? – NXT

+0

Compruebe las opciones de registro o depuración para el módulo FastCGI en Apache es una sugerencia. – mctylr

2

Voy a estar ondulado por la mano porque no he usado mod_fastcgi en mucho tiempo, y ha pasado un tiempo desde que eché un vistazo a su documentación.

Supongo que su módulo Perl no se está bifurcando, pero tarda un poco en ejecutarse, por lo que los clientes tardan un tiempo en procesar. Consulte Notas en el módulo FastCGI Apache mod_fastcgi sobre Señales utilizadas por FastCGI, y cómo los programas pueden desear manejar esas señales, incluyendo SIGPIPE.

+0

No hago nada en SIGPIPE excepto imprimir a STDERR que recibí un SIGPIPE. No estoy seguro de cómo cerraría una solicitud en proceso de todos modos. ¿Es ese el tipo de cosa donde debería establecer una bandera y verificar esa bandera ocasionalmente durante cualquier bucle de larga ejecución (que no tengo ninguno)? – NXT

+0

_durante cualquier bucle de ejecución prolongada (no es que yo tenga ninguno) _ Sospecho que ejecutar el clamscan, y esperar sus resultados es la gran demora. Si el usuario final aborta el script FastCGI, debido a que está impaciente esperando que se ejecute el antivirus, esto genera la señal SIGPIPE, tal como lo entiendo.Esto también bloquearía otras solicitudes web, esperando a que finalice el script Perl (que está esperando el antivirus), y si esos usuarios web también "detienen" o abortan sus conexiones, también generan señales SIGPIPE. - Toma todo esto con un grano de sal, ha pasado un tiempo. – mctylr

Cuestiones relacionadas