Forum PHP.pl

Witam.

Mam klasę typu errorhandler. error_log zapisuje błędy do pliku

[PHP] pobierz, plaintext 
error_log ($err, 3, $this->log_filename);
[PHP] pobierz, plaintext 

W __destruct jest funkcja w której sprawdzam

[PHP] pobierz, plaintext 
is_file($this->log_filename)
[PHP] pobierz, plaintext 

która zwraca FALSE. Gdy w tym samym skrypcie zapytam o historyczny log to zwraca TRUE i jest OK. file_exists - podobnie.

Czy ten error_log buforuje log i po zakończeniu skryptu dopiero go zapisuje?

Nie dałeś kodu, mamy zgadywać jak to napisałeś?

[PHP] pobierz, plaintext 
function __destruct () {
      if (is_file($this->log_filename)) {        // return false
      // Packing log file into ZIP package
            require_once ('zip.class.php');
            $zipfile = new zipfile;
            $zipfile->create_file(file_get_contents ($this->log_filename), basename($this->log_filename));
            file_put_contents ([b]$this->log_filename_zip[/b], $zipfile->zipped_file());
            unSet ($zipfile);
            unlink ($this->log_filename);        // Comment this line if You don't want delete original html file.
      }
 
      // Sending e-mail
      if ($this->send_mail == true AND (empty($this->send_deadline) OR (strtotime($this->send_deadline) > strtotime($this->date)))) {
            // ........
            $this->SendMail();     // return error with $this->log_filename_zip
      }
}
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
public function userErrorHandler($errno, $errmsg, $filename, $linenum, $vars='') {
            $err = file_get_contents ($this->ROOT . 'errorhandler_log.tpl');
            $search = Array ('$errno$', '$errmsg$', '$filename$', '$linenum$', '$vars$', '$id$');
            $replace = Array ($errno, $errmsg, $filename, $linenum, print_r($vars, 1), $id);
            $err = str_replace ($search, $replace, $err);
 
            error_log ($err, 3, $this->log_filename);
      }
}
[PHP] pobierz, plaintext 

Ten post edytował bulimaxiu 28.09.2011, 14:01:03

Zacznij od wywołania tej funkcji samodzielnie, nie w destruktorze, bo w tej metodzie lubią się dziać niezłe jaja z operacjami I/O.

Ręczne odpalenie serErrorHandler(999, 'msg', 'file', '$linenum', '$vars') powoduje, że destruktor działa prawidłowo - znajduje plik i wysyła maila.
Dla jasności dodam 2 rzeczy:
1. gdy wyeliminuję przyczynę błędu w kodzie, procedura się nie odpala - prawidłowo.
2. po zakończeniu skryptu plik log pojawia się w miejscu w którym miał się pojawić.

z automatu funkcja odpala się kodem

[PHP] pobierz, plaintext 
set_error_handler(Array($GLOBALS['eh'], 'userErrorHandler'), E_ALL);
[PHP] pobierz, plaintext 

Pozdrawiam.

Nie mówisz nam wszystkiego.


Mam na myśli ręczne odpalanie kodu, który jest w destruktorze.

Ręczne odpalenie kodu, który jest w destruktorze (poprzez wywołanie __destruct() ze skryptu jak zwykłej funkcji) powoduje zgłoszenie podwójnego komunikatu o nieznalezieniu pliku do przesłania.

Staram się przekazać konkrety, nikt nie chce chyba całej klasy analizować i zbędnego wydaje mi się kodu do tego problemu.

Ten post edytował bulimaxiu 28.09.2011, 15:09:04

Mam dziwne przeczucie, że chodziło o przerzucenie kodu destruktora do nowej funkcji i jej odpalenie.

Też tak zrobiłem, ale zachowanie było dokładnie takie samo: odwołanie się do pliku logu przed zakończeniem skryptu kończy się brakiem dostępu do pliku logu. Można to oczywiście obejść funkcją z fopen, ale chciałbym zrozumieć czemu tak się dzieje, bo w manualu nic o tym nie ma (bufor też czyściłem).

Na serwerze z innym systemem operacyjnym dzieje się to samo?

Tak. localhost WindowsXP (Vertrigo) PHP 5.3.6 oraz współdzielony Linux PHP 5.2.14
--------
Wyjaśnione. Przyczyną był błąd powstający w klasie errorhandler w sekcji wysyłania maila z raportem, ale już po obsłudze błędów (__destruct).
Gdy błąd występował wcześniej, plik się tworzył i wszystko było OK. Gdy błąd wystąpił tylko w __destruct, plik raportu się tworzył już po jego obsłudze wstępnej, w związku z czym pliku fizycznie jeszcze nie było. Jednak na dysku tuż po tym plik się pojawiał, tylko już nie był obsługiwany przez skrypt.
Wniosek: w errorhandlerze nie może być drobnego błędu.

Błąd logiczny, zawiły, ale wyjaśniony.

Pozdrawiam.

Ten post edytował bulimaxiu 6.10.2011, 11:11:27