2015-11-01 31 views
8

Dopo l'aggiornamento di PHP ho iniziato a ottenere i seguenti errori cron più volte al giorno:Cron sessionclean errori: trovano: `/ proc/xxxxx/fd ': Nessun file o directory

find: `/proc/xxxxx/fd': No such file or directory 

Proviene da PHP cron jobclasse:

[ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean 

Qualche idea?

+0

Hai provato a riavviare la macchina che lo ospita? ;) Puoi anche confermare il percorso della configurazione 'session.save_path'? –

+0

sessionclean tenta di aggiornare le sessioni per processi di php non esistenti. Forse dovresti riavviare la macchina o riavviare almeno Apache per aggiornare le informazioni sul processo php. – maxhb

+0

Il riavvio non aiuta. Session save_path è impostato su:/var/lib/php5/sessions Questi errori non si verificano ogni volta (sessionclean viene eseguito ogni 30 minuti e questo errore appare a volte più volte al giorno, a volte solo una volta in più giorni). Oltre a questo la maggior parte degli script usa il gestore di sessione personalizzato che significa che la cartella delle sessioni è quasi sempre vuota –

risposta

1

È possibile ignorare tali errori, la ricerca sessionclean per la sessione collegata a un pid non più esistente.

[ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean 2>/dev/null 

Si dovrebbe guardare all'interno della vostra directory di sessione per verificare che siano puliti correttamente perché tale messaggio potrebbe essere sintomatico di una troppo lunga lavorazione.

+0

Grazie per la tua risposta. Preferisco non sopprimere questi errori per essere avvisati se qualcosa non va nella sceneggiatura. La cartella delle sessioni viene pulita correttamente e quasi sempre è vuota poiché la maggior parte degli script utilizza il gestore di sessioni personalizzato. Ho controllato il contenuto della cartella: contiene i file di sessione correnti e di solito ha solo un paio di file, se presenti. Mi chiedo quale sia la vera causa di questo problema e come risolverlo (invece di sopprimere l'errore) ... –

+0

Non c'è niente di sbagliato: il processo è terminato durante l'esecuzione dello script sessionclean. Se non vuoi sopprimere altri errori, devi modificare lo script. – Adam

+0

@Adam Anche io sto avendo questo problema, ma non so cosa pensarlo. In /etc/php5/apache2/php.ini non ho un 'save_path', ma in/var/lib/php5/sessions ci sono 2 file di sessione datati da un paio di ore fa. Penso che dovrebbero essere lì, ma non so come essere sicuro. Inoltre, xxxx in '/ proc/xxxx/fd' è coerente per i processi attivi di apache2. Non sono sicuro di cosa pensare. – Opux

0

Ho trovato un modo per eliminare gli errori, anche se, tutte le scommesse sono spente se si sta eliminando un problema o semplicemente mascherandolo. Ho diversi contenitori in esecuzione e alcuni hanno questo problema mentre altri no.

Il/usr/lib/PHP5/sessionclean che genererà l'errore è:

#!/bin/sh -e 

SAPIS="apache2:apache2\napache2filter:apache2\ncgi:php5\nfpm:php5-fpm\n" 

# Iterate through all web SAPIs 
(
printf "$SAPIS" | { \ 
proc_names="" 
while IFS=: read -r conf_dir proc_name; do 
    if [ -e /etc/php5/${conf_dir}/php.ini ]; then 
     # Get all session variables once so we don't need to start PHP to get each config option 
     session_config=$(php5 -c /etc/php5/${conf_dir}/php.ini -d "error_reporting='~E_ALL'" -r 'foreach(ini_get_all("session") as $k => $v) echo "$k=".$v["local_value"]."\n";') 
     save_handler=$(echo "$session_config" | sed -ne 's/^session\.save_handler=\(.*\)$/\1/p') 
     save_path=$(echo "$session_config" | sed -ne 's/^session\.save_path=\(.*\)$/\1/p') 
     gc_maxlifetime=$(($(echo "$session_config" | sed -ne 's/^session\.gc_maxlifetime=\(.*\)$/\1/p')/60)) 

     if [ "$save_handler" = "files" -a -d "$save_path" ]; then 
      proc_names="$proc_names $proc_name"; 
      printf "%s:%s\n" "$save_path" "$gc_maxlifetime" 
     fi 
    fi 
done 
# first find all open session files and touch them (hope it's not massive amount of files) 
for pid in $(pidof $proc_names); do 
    find "/proc/$pid/fd" -ignore_readdir_race -lname "$save_path/sess_\*" -exec touch -c {} \; 
done 
}) | sort -rn -t: -k2,2 | sort -u -t: -k 1,1 | while IFS=: read -r save_path gc_maxlifetime; do 
    # find all files older then maxlifetime and delete them 
    find -O3 "$save_path" -depth -mindepth 1 -name 'sess_*' -ignore_readdir_race -type f -cmin "+$gc_maxlifetime" -delete 
done 

exit 0 

Ma se sostituisco che w/a/usr/lib/PHP5/sessionclean da un contenitore che non lo fa genera l'errore, che è:

#!/bin/sh -e 

SAPIS="apache2:apache2\napache2filter:apache2\ncgi:php5\nfpm:php5-fpm\n" 

# Iterate through all web SAPIs 
(
proc_names="" 
printf "$SAPIS" | \ 
while IFS=: read -r conf_dir proc_name; do 
    if [ -e /etc/php5/${conf_dir}/php.ini ]; then 
     # Get all session variables once so we don't need to start PHP to get each config option 
     session_config=$(php5 -c /etc/php5/${conf_dir}/php.ini -d "error_reporting='~E_ALL'" -r 'foreach(ini_get_all("session") as $k => $v) echo "$k=".$v["local_value"]."\n";') 
     save_handler=$(echo "$session_config" | sed -ne 's/^session\.save_handler=\(.*\)$/\1/p') 
     save_path=$(echo "$session_config" | sed -ne 's/^session\.save_path=\(.*\)$/\1/p') 
     gc_maxlifetime=$(($(echo "$session_config" | sed -ne 's/^session\.gc_maxlifetime=\(.*\)$/\1/p')/60)) 

     if [ "$save_handler" = "files" -a -d "$save_path" ]; then 
      proc_names="$proc_names $proc_name"; 
      printf "%s:%s\n" "$save_path" "$gc_maxlifetime" 
     fi 
    fi 
done 
# first find all open session files and touch them (hope it's not massive amount of files) 
for pid in $(pidof $proc_names); do 
    find "/proc/$pid/fd" -ignore_readdir_race -lname "$save_path/sess_\*" -exec touch -c {} \; 
done 
) | sort -rn -t: -k2,2 | sort -u -t: -k 1,1 | while IFS=: read -r save_path gc_maxlifetime; do 
    # find all files older then maxlifetime and delete them 
    find -O3 "$save_path" -depth -mindepth 1 -name 'sess_*' -ignore_readdir_race -type f -cmin "+$gc_maxlifetime" -delete 
done 

exit 0 

Quindi non ottengo gli errori.

2

A questo punto è stato segnalato un bug Debian (e fixed).

Si parla di un rilascio a stabile:

Nel prossimo caricati di sicurezza, per esempio circa due settimane dopo il 5.6.23 è rilasciato , a meno che non emerga qualcos'altro di critico.

5.6.23 è fuori, quindi mi aspetto che entro le prossime due settimane.

La correzione c'è da aggiungere

if [ -d "/proc/$pid/fd" ]; then 

prima del comando

find "/proc/$pid/fd" 

.