2015-11-01 19 views
8

Po uaktualnieniu PHP zacząłem się następujące błędy Cron kilka razy dziennie:Cron sessionclean błędy: find: `/ proc/xxxxx/fd ': Nie ma takiego pliku lub katalogu

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

Pochodzi z PHP sessionclean cron job:

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

Jakieś pomysły?

+0

Czy próbowałeś ponownie uruchomić urządzenie, które go obsługuje? ;) Czy możesz również potwierdzić ścieżkę konfiguracji 'session.save_path'? –

+0

sessionclean próbuje zaktualizować sesje dla nieistniejących procesów php. Może powinieneś zrestartować komputer lub przynajmniej ponownie uruchomić Apache, aby zaktualizować informacje o procesie php. – maxhb

+0

Ponowne uruchomienie nie pomaga. Sesja save_path jest ustawiona na:/var/lib/php5/sessions Błędy te nie występują za każdym razem (sessionclean działa co 30 minut, a te błędy pojawiają się czasami kilka razy dziennie, czasami tylko raz na kilka dni). Oprócz tego większość skryptów używa niestandardowej procedury obsługi sesji, co oznacza, że ​​folder sesji jest prawie zawsze pusty. –

Odpowiedz

1

Możesz zignorować te błędy, wyszukiwanie sessionclean sesji dołączone do nieistniejącego pid.

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

Powinieneś zajrzeć do swojego katalogu sesji, aby sprawdzić, czy są one poprawnie wyczyszczone, ponieważ taka wiadomość może być symptomem zbyt długiego przetwarzania.

+0

Dziękuję za odpowiedź. Wolę nie pomijać tych błędów, aby otrzymywać powiadomienia, jeśli coś jest nie tak ze skryptem. folder sesji jest poprawnie czyszczony i prawie zawsze pusty, ponieważ większość skryptów używa niestandardowej procedury obsługi sesji. Sprawdziłem zawartość folderu - zawiera on bieżące pliki sesji i zwykle ma tylko kilka plików, jeśli takie istnieją. Zastanawiam się, jaka jest prawdziwa przyczyna tego problemu i jak go rozwiązać (zamiast tłumienia błędu) ... –

+0

Nie ma nic złego: proces zakończył się podczas wykonywania skryptu sessionclean. Jeśli nie chcesz tłumić żadnego innego błędu, musisz zmodyfikować skrypt. – Adam

+0

@Adam Mam również ten problem, ale nie wiem, co o tym myśleć. W /etc/php5/apache2/php.ini nie mam 'save_path', ale w/var/lib/php5/sessions znajdują się 2 pliki sesji datowane na kilka godzin wcześniej. Myślę, że powinni tam być, ale nie wiem, jak się upewnić. Ponadto, xxxx w '/ proc/xxxx/fd' jest konsekwentnie dla aktywnych procesów apache2. Nie jestem pewien, co myśleć. – Opux

0

Znalazłem sposób na wyeliminowanie błędów, chociaż wszystkie zakłady są wyłączone, czy eliminujesz problem, czy po prostu go maskujesz. Mam kilka kontenerów uruchomionych, a niektóre mają ten problem, a inne nie.

/usr/lib/php5/sessionclean który wygeneruje błąd jest:

#!/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 

Ale jeśli mogę wymienić, że w/a/usr/lib/php5/sessionclean z pojemnika, który nie wygenerować błąd, który jest:

#!/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 

Wtedy nie dostaję błędów.

2

Jest teraz zgłoszony błąd Debiana (i fixed) na ten temat.

Wspomina o dopuszczenia do stabilny

W kolejnym przesyłania bezpieczeństwa, np mniej więcej dwa tygodnie po 5.6.23 jest wydany , chyba że pojawi się coś innego krytycznego.

5.6.23 wychodzi, więc spodziewam się tego w ciągu najbliższych dwóch tygodni.

Rozwiązaniem jest dodanie

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

przed komendą

find "/proc/$pid/fd" 

.

Powiązane problemy