<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Noch ein paar andere Ideen. Du hast:<div class=""><br class=""></div><div class=""><div class="">/etc/php/7.3/cli/php.ini</div><div class="">max_execution_time => 0 => 0</div><div class=""><br class=""></div><div class="">Also *darf* das nicht passieren. Wo kommen also die 30 Sekunden her? Hast Du noch eine .ppm.json in der die drin stehen könnten? Siehe <span style="color: rgb(166, 226, 46); text-decoration: underline; font-family: Menlo, Monaco, "Courier New", monospace; white-space: pre; background-color: rgb(39, 40, 34);" class="">ConfigTrait.php</span> wo die ausgelesen werden.</div><div class=""><br class=""></div><div class="">Ansonsten ändere mal bitte im ProcessManager das <span style="color: rgb(230, 219, 116); font-family: Menlo, Monaco, "Courier New", monospace; white-space: pre; background-color: rgb(39, 40, 34);" class="">set_time_limit(0);</span></div><div class=""><div>in <span style="color: rgb(230, 219, 116); font-family: Menlo, Monaco, "Courier New", monospace; white-space: pre; background-color: rgb(39, 40, 34);" class="">var_dump(set_time_limit(0));</span> - ich würde gerne sehen ob das überhaupt erfolgreich ist.</div><div><br class=""></div><div>Viele Grüße, Andreas</div><div><br class=""><blockquote type="cite" class=""><div class="">On 24. Nov 2019, at 10:08, Andreas Goetz <<a href="mailto:cpuidle@gmail.com" class="">cpuidle@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Passiert der Timeout auch wenn die Aggregation läuft? Sollte ja eigentlich da vom gleichen PHP Interpreter ausgeführt?<br class=""><br class="">Viele Grüße, Andreas <br class=""><br class=""><blockquote type="cite" class="">Am 23.11.2019 um 23:45 schrieb <a href="mailto:joekokker@epios.eu" class="">joekokker@epios.eu</a>:<br class=""><br class="">Hallo,<br class=""><br class="">danke für die Rückmeldungen! Mittlerweile bin ich etwas weitergekommen.<br class=""><br class="">Ich habe die benötigten php-Pakete (laut Webseite) und zusätzlich php-cgi neu installiert. Dann konnte ich den ppm sowohl mit /usr/bin/php und auch /usr/bin/php-cgi ohne Fehler starten. Es hat aber keinen Unterschied gemacht. Kann das sein?<br class=""><br class="">Die Middleware/Frontend verhält sich normal. Der Fehler ist aber immer noch vorhanden. Er tritt auch auf wenn ich viele Channels gleichzeitig lade.<br class=""><br class="">@Frank: Ich habe aggregation nur auf einigen Channels:<br class="">php /var/www/<a href="http://volkszaehler.org/bin/aggregate" class="">volkszaehler.org/bin/aggregate</a> run <UUID> -m full -l day -l hour -l minute<br class=""><br class="">Aber das Timeout ist immer noch da. Es ist sehr komisch, da im File "vendor/bin/ppm", das man startet, gleich am Anfang das Timeout mit "set_time_limit(0);" ausgesetzt wird. Es scheint aber nicht angenommen zu werden. Bei mir steht nach dem Start php[9423]: | max-execution-time | 30<br class=""><br class="">Was ist euer Output von /usr/bin/php-cgi vendor/bin/ppm [...]?<br class=""><br class="">Beste Grüße<br class="">Joe<br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On 11/23/19 8:36 PM, Andreas Goetz wrote:<br class="">Ich glaube dass Du bzgl. Pcntl in die falsche INI schaust. Cli und Cgi haben m.W. getrennte Dateien. Sorg bitte erstmal dafür, dass PPM wie vorgesehen mit cgi läuft, dann schauen wir nach weiteren Optionen.<br class="">Viele Grüße, Andreas<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Am 23.11.2019 um 19:40 schrieb <a href="mailto:joekokker@epios.eu" class="">joekokker@epios.eu</a>:<br class=""></blockquote><br class="">Hallo,<br class=""><br class="">vielen Dank für die Hilfe. Ich habe momentan nicht auf allen Kanälen aggregation aktiviert. Zudem lade ich sehr viel Daten aus der Datenbank. Bei "normaler" Nutzung tritt der Fehler nicht auf.<br class=""><br class="">Mit umbiegen, meinst du die "url" in der options.js Datei auf "" zu ändern, oder? Kann man dann das Frontend direkt nutzen? Irgendwie klappt das nicht bei mir.<br class=""><br class="">ls -l /usr/bin/php*:<br class="">/usr/bin/php -> /etc/alternatives/php<br class="">/usr/bin/php7.3<br class="">/usr/bin/php-cgi -> /etc/alternatives/php-cgi<br class="">/usr/bin/php-cgi7.3<br class=""><br class="">ls -l /etc/alternatives/php*<br class="">/etc/alternatives/php -> /usr/bin/php7.3<br class="">/etc/alternatives/php.1.gz -> /usr/share/man/man1/php7.3.1.gz<br class="">/etc/alternatives/php-cgi -> /usr/bin/php-cgi7.3<br class="">/etc/alternatives/php-cgi.1.gz -> /usr/share/man/man1/php-cgi7.3.1.gz<br class="">/etc/alternatives/php-cgi-bin -> /usr/lib/cgi-bin/php7.3<br class=""><br class="">php -r 'phpinfo();' | grep -i api:<br class="">Server API => Command Line Interface<br class="">PHP API => 20180731<br class="">Zend Extension Build => API320180731,NTS<br class="">PHP Extension Build => API20180731,NTS<br class="">GSSAPI => Yes<br class="">DOM/XML API Version => 20031129<br class="">MHASH API Version => Emulated Support<br class="">Client API library version => mysqlnd 5.0.12-dev - 20150407 - $Id: 7cc7cc96e675f6d72e5cf0f267f48e167c2abb23 $<br class="">API Extensions => mysqli,pdo_mysql<br class="">Client API version => mysqlnd 5.0.12-dev - 20150407 - $Id: 7cc7cc96e675f6d72e5cf0f267f48e167c2abb23 $<br class="">Phar API version => 1.1.1<br class="">opcache.restrict_api => no value => no value<br class=""><br class="">Ich habe versucht die binary "/usr/bin/php /home/volkszaehler/volkszaehler/vendor/bin/ppm [...]" mit /usr/bin/php-cgi zu ersetzten. Das wirft aber den Fehler, dass "PCNTL is not enabled in the PHP installation at /usr/bin/php-cgi7.3.". Es ist aber in der Module Liste. Das gleiche, wenn ich nur den "--cgi-path" ändere.<br class=""><br class="">Glaubst du, dass es eine Einstellung in der php.ini ist? Oder ein Problem der Installation? Oder vielleicht ein Rechteproblem? Oder könnte es von der Datenbank kommen?<br class=""><br class="">Beste Grüße<br class="">Joe<br class=""><br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On 11/23/19 6:40 PM, Andreas Goetz wrote:<br class="">Hi,<br class="">Was tun… also erstmal Fehlerquellen reduzieren- also direkt auf den PPM gehen und Apache mal weglassen. Wenn Du das Frontend nicht umbiegen willst tuts ja auch curl.<br class="">Dann wundert mich der Timeout bei “langen Zeitreihen”. Was meinst Du damit- hast Du Aggregation aktiviert? Damit sollte es egtl. keine langsamen Abfragen geben, es sei denn Du lädst Unmengen an Daten.<br class="">Dann ist Dein ppm cgi-path /usr/bin/php. Bist Du sicher, dass das ein php-cgi ist? Was sagt<br class="">   php -r 'phpinfo();' | grep -i api<br class="">Viele Grüße,<br class="">Andreas<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On 23. Nov 2019, at 17:46, <a href="mailto:joekokker@epios.eu" class="">joekokker@epios.eu</a> wrote:<br class=""></blockquote><br class="">Hallo,<br class=""><br class="">Der Fehler tritt auf wenn ich große Zeitreihen lade. Im Frontend kommt der Fehler "Gateway Timeout", zwischendurch auch "Service Temporarily Unavailable".<br class=""><br class="">Die Konfiguration ist ein apache vor dem ppm mit rewrite. Sobald ich noch einmal die gleiche Zeitspanne lade, zeigt das Frontend die Daten an. Ich denke, dass das durch das Cachen des SQL Servers dann schneller geht.<br class=""><br class="">Hier ist der Output des ppm processes während des Fehlers.<br class=""><a href="https://pastebin.com/MDRjagFJ" class="">https://pastebin.com/MDRjagFJ</a><br class=""><br class="">Die php version ist: PHP 7.3.11-1~deb10u1 (cli) (built: Oct 26 2019 14:14:18) ( NTS )<br class=""><br class="">Der Output von php -m ist: https://pastebin.com/eJPCggAf<br class="">Der Output von php -i ist: https://pastebin.com/eVRG5Us4<br class=""><br class="">Wo könnte ich am besten ansetzten?<br class=""><br class="">Beste Grüße<br class="">Joe<br class=""><br class=""><br class=""><br class="">On 11/23/19 3:28 PM, Andreas Goetz wrote:<br class=""><blockquote type="cite" class="">Mir kommt das sehr seltsam vor. Der Prozess ist ja longrunning, soll also nicht nach 30sec gekillt werden. Ausserdem sollte ein gekillter Worker automatisch durch einen neuen ersetzt werden- und nicht erst auf einen Fehler laufen.<br class="">Long Story short: ein paar mehr Infos zu PHP Version, cli/cgi, ini, log etc könnten vielleicht helfen.<br class="">Viele Grüße, Andreas<br class=""><blockquote type="cite" class="">Am 23.11.2019 um 13:44 schrieb joekokker@epios.eu:<br class=""><br class="">Hallo,<br class=""><br class="">ich ziehe gerade meinen Volkszaehler auf die neueste git (master) Version. Dieses Mal möchte ich die Middleware als Stand Alone Version als ppm laufen lassen.<br class=""><br class="">Leider erhalte ich dabei einen Gateway Timeout, der im Log folgende Fehler wirft:<br class=""><br class="">php[21101]: Maximum execution time of 30 seconds exceeded. Closing worker.<br class=""><br class="">Es scheint, dass php einfach die Worker killt. Das Standard Timeout is 30 Sekunden. Mir kommt es komisch vor einfach in der php.ini das Timeout global hochzusetzten. Ich habe leider keine Einstellungsmöglichkeit in der htdocs/js/options.js File oder im /etc/middleware.json gefunden.<br class=""><br class="">Wie habt ihr das gelöst? Ich wäre um einen Hinweis sehr dankbar.<br class=""><br class="">Gibt es andere besondere Einstellungen, die noch nötig/sinnvoll sind beim Betrieb mit PPM?<br class=""><br class="">Beste Grüße<br class="">Joe<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></div></div></blockquote></div><br class=""></div></div></body></html>