Unter dem Piwik Installationspfad gibt es unter pfad_zu_piwik/misc/cron das Aufräum-Skript “archive.php” für die Auto-Archivierung. Das Skript lief seit Wochen problemlos jede Stunde. Seit einer Woche spuckt das Skript jetzt folgende Fehlermeldung aus:
PHP Fatal error: 2 total errors during this script execution, please investigate and try and fix
these errors. First error was: Got invalid response from API request:
http://www.seite_bla_blubb.de/piwik/index.php?module=API&method=VisitsSummary.getVisits&idSite=1&period=day&date=last2&format=php&token_auth=xxxxxxx&trigger=archivephp.
Response was 'curl_exec: Empty reply from server' in /var/www/piwik/html/misc/cron/archive.php on line 179
und
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes)
in /var/www/piwik/html/core/DataTable.php on line in /var/www/piwik/html/misc/cron/archive.php on line 179
Mit Fehler eins kann ich leider aufgrund mangelnder PHP Kenntnisse nichts anfangen. Fehler 2 sagt mir schon mehr, obwohl der Fehler keinen Sinn macht. Das Skript wollte sich von erlaubten 134217728 bytes ( 128MB ) unglaubliche 32 Bytes reservieren und durfte das nicht??!??
Line 179 bzw. der Block drum rum sieht so aus:
public function logFatalError($m)
{
// debug_print_backtrace();
$this->log("ERROR: $m");
trigger_error($m, E_USER_ERROR);
exit;
}
Wie rufst Du denn das Skript auf? Eigentlich ruft man dort archive.sh und nicht .php auf. Dieses sollte per Cronjob direkt auf dem Server aufgerufen werden.
Memory Limit in der php.ini erhöhen oder den Provider das erhöhen lassen. Dann sollte es gehen. Ich vermute mal, dass das erste Problem auch davon stammt - oder eben archive.sh per Cronjob aufrufen, dann gibt es auch meist mehr Speicher zur Verfügung ;-).
= More information =
This script is an optimized rewrite of archive.sh in PHP, allowing for more flexibility
and better near real-time performance when Piwik tracks thousands of websites.
Daher habe ich dieses Skript verwendet. Mit dem archive.sh Skript hatte ich auch nur Probleme (Seg-Faults). Dazu gibt es noch einen anderen Post.
[quote=“Thomas Seifert”]
Memory Limit in der php.ini erhöhen oder den Provider das erhöhen lassen. Dann sollte es gehen. Ich vermute mal, dass das erste Problem auch davon stammt - oder eben archive.sh per Cronjob aufrufen, dann gibt es auch meist mehr Speicher zur Verfügung ;-).[/quote]
Werde ich probieren. BTW: Muss man nachdem man unter
/etc/php5/cli/php.ini
etwas geändert hat den Apache neu starten bzw. reicht ein
Wenn Du in cli/php.ini was änderst, dann wird das das cli php beeinflussen und nicht das im Webserver, daher musst Du den Webserver nicht neu starten. Allerdings würde ich auch, eben weil das archive.php Archivierungsanfragen an den Webserver richtet, das memory limit und die max execution time für das php im Webserver deutlich erhöhen. Laut Aussage im Ticket wird zwar das memory limit von piwik im Falle der Archivierung eigenmächtig erhöht aber nur wenn es das auch darf.
Ich habe jetzt für cli und für den Apache und Suhosin “memory_limit = 192M” gesetzt. War vorher bei 128M. Scheint zu laufen. Zumindest bleiben die Fehler aus. Ich werde weiter beobachten. Danke für die Anmerkungen!
[quote=“Thomas Seifert”]
Wenn Du in cli/php.ini was änderst, dann wird das cli php beeinflussen und nicht das im Webserver, daher musst Du den Webserver nicht neu starten.[/quote]
Ich würd zur Sicherheit in dem Falle einen restart des Apache machen. Meines Wissens sollte Reload einen “Graceful Restart” machen, was theoretisch reichen sollte. Ich geh nur halt lieber auf Nummer sicher. Die 5 Sekunden Ausfall von einem Restart sollten vertretbar sein.
Wenn du aber ein Shop-System betreibst und du gerade 50 Kunden auf der Kiste hast und du einen Apache “Restart” machst reißt du den Leuten aber die Session ab. Daher bin ich da immer etwas vorsichtig. “Graceful Restart” lässt die Session meines Wissens nach auslaufen bis kein Request mehr kommt…
Sessions werden separat gespeichert, im Dateisystem oder der Datenbank. Die sollten da nicht abreißen. Maximal die Connection, wenn sie genau in diesem Moment laden, dürfte abreißen.
Darum macht man solche Arbeiten auch in der Regel zu Betriebsarmen Zeiten ;-).
Ich muss nochmal nerven. Das Skript lief jetzt 2 Tage sauber durch. Jetzt kommt die Meldung:
PHP Fatal error: 1 total errors during this script execution, please investigate and try and fix these errors. First error was: Got invalid response from API request: http://www.seite_bla_blubb.de/piwik/index.php?module=API&method=VisitsSummary.getVisits&idSite=1&period=day&date=last2&format=php&token_auth=69xxxx&trigger=archivephp. Response was 'curl_exec: Empty reply from server' in /var/www/piwik/html/misc/cron/archive.php on line 179
Kann das was mit der “max execution time” zu tun haben???
Mich würde mal interessieren, ob es hierzu denn nun eine Lösung gibt. Ich habe komischerweise seit ca. 6 Tagen das gleiche Problem. Die Archivierungen per Cron den Tag über laufen, immer Nachts schmiert der Server aber ab mit “/USR/SBIN/CRON[23843]: (CRON) error (grandchild #23844 failed with exit status 255)”. Dann ist der Apache komplett tot und muss neu gestartet werden.
Habe auch schon alle Logs aktiviert, die man aktivieren konnte und in keinem steht was dazu, nur diese eine Meldung vom Cron in zu finden.
Und, wenn ich die archive.php manuell auf der Console starte, dann stürzt der Apche nicht ab. Das ist immer nur beim Cron.
Bitte mal in der shell “which php5” ausführen und schauen, ob “/usr/bin/php” der richtige Pfad zu PHP ist. Falls etwas anderes angezeigt wird, bitte austauschen.
Die .sh vorher lief ja auch immer fehlerfrei! Aber seit der letzten Version von Piwik bekomme ich nur noch diese Fehler. Heute auch wieder. Schon den ganzen Tag. Hab auch schon die ganz neue archive.php aus der Dev versucht, bringt auch nichts. Und witzig ist vor allem, dass seit dem die .sh auch nicht mehr geht.
Archiving was last executed without error 1 Tage 16 Stunden ago
Der Fehler ist eigentlich zu 99% immer bei der Site ID 1 und ca. zu 40% auch noch bei der Site ID 2. Das sind meine beiden größten Seiten. Und da jeweils auch immer bei der Monats-Archivierung.
Da muss sich dringend etwas ändern, denn so ist es nicht mehr nutzbar. Memory-Limit habe ich schon bei 1,5 GB, mehr gibt der Server nicht her. Ist jetzt schon zu viel, da es duraus zu Speicherengpässen mit anderen Programmen kommen kann. Also weiter hoch kann ich nicht, ich muss wenn schon weiter runter.
Hab auch schon mal versucht in der archive.php etwas zu sehen oder etwas zu modifizieren, aber da steige ich nicht wirklich durch. Mir ist absolut unklar, warum die an der Stelle so viel Speicher braucht, obwohl ja nur eine Zahl als Antwort kommt. Kann man so eine Berechnung denn nicht die DB machen lassen? Aktuell scheint ja wohl PHP das alles verarbeiten zu müssen. Oder zumindest häppchenweise?
Ich meinte ja den Fall wenn man etwas an der php.ini für den Apache ändert…