2010-02-21 12 views
7

mio Perl web-app, in esecuzione sotto Apache mod_fastcgi, ottiene spesso errori come il seguente:Che cosa significa "Massimo numero di segnali in attesa (120) superato" significa?

massima conteggio dei segnali pendenti (120) ha superato alla linea 119.

che ho visto questo accade in relazione al caricamento di file, ma non sono sicuro che sia lo l'unica volta che succede. Ho anche ricevuto SIGPIPE subito (o forse dopo) ho ricevuto quell'errore.

Qualche idea?

EDIT Grazie per i suggerimenti a tutti. Qualcuno ha chiesto quale fosse la linea 119. Spiacente, dovrei averlo inserito. È in un blocco di codice in cui eseguo il controllo dei virus su un file caricato. Non ottengo l'errore ogni volta, solo occasionalmente.

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

domanda ovvia: cos'è la riga 119? – ysth

+0

quando perl si lamenta in questo modo, esce o perde solo quei segnali? – mcr

risposta

7

significa che il sistema operativo è fornire segnali a Perl più velocemente di quanto possa gestire, ed è stato raggiunto il punto di saturazione. Tra le operazioni, Perl salva i segnali da gestire e li gestisce una volta che ha una possibilità. Si ottiene questo errore perché sono stati ricevuti troppi segnali prima che Perl avesse la possibilità di riprendere fiato. Questo è un errore fatale, quindi il tuo processo Perl termina.

La soluzione è capire cosa sta generando così tanti segnali. Vedi here per ulteriori dettagli.


Update: La mia risposta originale era un po 'imprecise, dicendo che la generazione di un nuovo processo di Perl era parte del problema, quando in realtà non lo era. Ho aggiornato in base al commento di @ ysth di seguito.

+1

niente a che fare con l'avvio di un nuovo processo; perl cattura i segnali e li salva per essere spediti in un punto sicuro tra le operazioni, e questo errore indica che molti segnali sono stati ricevuti prima di quel punto sicuro. – ysth

+0

Hai qualche idea su come scoprire da dove viene il segnale? – NXT

+0

Controllare le opzioni di registrazione o di debug per il modulo FastCGI in Apache è un suggerimento. – mctylr

2

Sarò ondulato a mano perché non ho usato mod_fastcgi da molto tempo, ed è passato un po 'di tempo da quando ho guardato la sua documentazione.

Immagino che il tuo modulo Perl non stia biforcandosi, ma impiega un po 'di tempo per essere eseguito, così che il client si richieda un po' per l'elaborazione. Vedi Note sotto il modulo Apache FastCGI mod_fastcgi sui segnali utilizzati da FastCGI e su come i programmi potrebbero voler gestire quei segnali, incluso SIGPIPE.

+0

Non faccio nulla su SIGPIPE tranne che per stampare su STDERR che ho ricevuto un SIGPIPE. Non sono sicuro di come avrei comunque interrotto una richiesta di processo. È questo il tipo di cosa in cui dovrei impostare una bandiera e controllare quella bandiera di tanto in tanto durante qualsiasi loop di lunga durata (non che ne abbia)? – NXT

+0

_durante qualsiasi loop di lunga durata (non che ne abbia) _ Ho il sospetto che sia in esecuzione il clamscan, e in attesa dei suoi risultati è il lungo ritardo. Se l'utente finale interrompe lo script FastCGI, poiché è impaziente nell'attesa che venga eseguito lo scanner antivirus, questo genera il segnale SIGPIPE, a quanto ho capito.Ciò bloccherebbe anche altre richieste web, in attesa che lo script Perl finisca (che è in attesa dello scanner antivirus), e quindi se anche quegli utenti web "fermano" o interrompono le loro connessioni, anch'essi generano anche segnali SIGPIPE. - Prendi tutto questo con un pizzico di sale, è passato un po 'di tempo. – mctylr