Fehler bei Auto Archivierung mit archive.php Skript


#1

Hallo Piwik Benutzer.

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;
        }

Für Hilfe wäre ich sehr dankbar!


(Thomas Seifert) #2

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 ;-).


#3

[quote=“Thomas Seifert”]
Wie rufst Du denn das Skript auf?[/quote]
Das Skript wird per Cronjob direkt auf dem Server aufgerufen:


# PIWIK AUTO ARCHIVING
5 * * * *       /usr/bin/php /var/www/piwik/html/misc/cron/archive.php www.seite_bla_blub.de/piwik 3600 > /var/log/piwik_new.log

Im archive.php Skript steht folgendes:


= 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

/etc/init.d/apache reload

???


(Thomas Seifert) #4

Nun ja, dieses Skript war mir beim Release entgangen aber es erbt die gleichen Probleme meines Erachtens, wie auch die browserbasierte Archivierung: enge Limits auf Webserverebene. Habe ich auch im zugehörigen Ticket geschrieben New optimized archive.php script for faster and optimized archiving when hundreds/thousands of websites · Issue #2327 · matomo-org/matomo · GitHub und würde zumindest beim aktuellen Stand weiter die archive.sh empfehlen. Die im anderen Post genannten Segfaults würde ich auch eher auf kaputte PHP-Teile zurückführen oder vielleicht ebenso das memory limit in Verbindung mit suhosin.

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.


#5

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]

Reicht dann eigentlich ein

/etc/init.d/apache reload

oder muss es ein

/etc/init.d/apache restart

sein?


(Thomas Seifert) #6

Wenn Du nur für die Cli änderst, dann brauchst Du den Apache überhaupt nicht anrühren ;).


#7

[quote=“Thomas Seifert”]
Wenn Du nur für die Cli änderst, dann brauchst Du den Apache überhaupt nicht anrühren ;).[/quote]

Das ist mir klar :slight_smile: Ich meinte ja den Fall wenn man etwas an der php.ini für den Apache ändert…


(Thomas Seifert) #8

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.


#9

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…


(Thomas Seifert) #10

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 ;-).


#11

Jaja :slight_smile: Also zwischen 0h und 0:30 wenn ich ins Bett gehe :slight_smile:


(Thomas Seifert) #12

Oder man stellt sich den Wecker auf 3 Uhr morgens :-P.


#13

Wunschdenken von Chefs :wink:


#14

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???


(Thomas Seifert) #15

Hast Du ein error log von php oder dem Webserver? Da sollte sein Problem mit einer Fehlermeldung beschrieben sein.


#16

Da hatte ich auch schon geschaut. In

/var/log/php/php_errors.log

ist nichts zu finden.

Im Syslog steht nur, dass der Prozess stirbt:


Nov 11 15:05:01 kiste1 /USR/SBIN/CRON[8180]: (root) CMD (/usr/bin/php /var/www/piwik/html/misc/cron/archive.php www.blablubb.de/piwik 3600 > /var/log/piwik_new.log)
Nov 11 15:05:01 kiste1 /USR/SBIN/CRON[8181]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Nov 11 15:05:04 kiste1 /USR/SBIN/CRON[8179]: (CRON) error (grandchild #8180 failed with exit status 255)

Blöd!


(Thomas Seifert) #17

Und error log vom Webserver? Normalerweise kommt irgendwie die eigentliche Fehlermeldung von php reported.


(edvsb) #18

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.


(Peterbo) #19

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.


(edvsb) #20
h82xxx:~# which php5
/usr/bin/php5
h82xxx:~#

Also das scheint wohl auch zu passen.

15 * * * * www-data /usr/bin/php5 /var/www/pfad/public_html/piwik/misc/cron/archive.php --url=http:/url-zu-piwik/

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?