Verandering in php.ini wordt niet doorgevoerd na restart

[keranoz]

Hallo,

Een paar geleden heb ik Piwik gedownload en een poging gedaan tot installeren. Kwam alleen niet heel ver:



Nu heb ik dit in de php.ini file aangepast en de webserver geherstart maar Piwik blijft hierom zeuren. Ik gebruik php 5.6. Ik lees dat sinds deze versie de variabele '$HTTP_RAW_POST_DATA' deprecated is en 'always_populate_raw_post_data' naar -1 te zetten de oplossing is om de E_DEPRECATED melding weg te houden.

Nu heb ik deze aanpassing gedaan in de php.ini die nginx gebruikt bij mij (/etc/php5/fpm/php.ini). Ik weet vrij zeker dat dit de goede file is. In phpinfo() staat deze file ook aangegeven.

Maar het probleem is nu, het lijkt wel alsof deze aanpassing compleet genegeerd wordt. Piwik zeurt hier nog steed om ondanks deze aanpassing. Ik lees op internet eigenlijk dat er niet veel mensen zijn die dit probleem hebben. (Lees: ik heb geen ander geval die hetzelde heeft als ik kunnen vinden)

Weet iemand hier raad mee? Zou heel fijn zijn!

Gr.
Tom

Btw, ik hoop dat dit de goede plaats is op het forum voor dit topic...

Wat bronnen:
https://issues.piwik.org/6465
https://bugs.php.net/bug.php?id=66763 (Lees vooral de comments)
https://www.bram.us/2014/...oved-in-a-future-version/

Server draait op Debian Jessie icm. PHP 5.6.13-0+deb8u1 en Nginx.

[azerty]

Vreemd, bij mij heeft dit wel geholpen... (ook Jessie met zelfde php versie).

Heb je je php pool herstart, of enkel nginx?

Edit:



en mijn '/etc/php5/fpm/php.ini':

; Always populate the $HTTP_RAW_POST_DATA variable. PHP's default behavior is
; to disable this feature and it will be removed in a future version.
; If post reading is disabled through enable_post_data_reading,
; $HTTP_RAW_POST_DATA is *NOT* populated.
; http://php.net/always-populate-raw-post-data
always_populate_raw_post_data = -1

[ Voor 63% gewijzigd door azerty op 11-10-2015 18:49 ]

[Antrax]

Doe je de 'always_populate_raw_post_data' dan in de root van de Piwiki php.ini file of in /etc/php5/fpm/php.ini?

De webserver staat in dit geval los van de fpm app? Heb je die ook herstart?

[keranoz]

iRicardo schreef op zondag 11 oktober 2015 @ 18:42:
De webserver staat in dit geval los van de fpm app? Heb je die ook herstart?

azerty schreef op zondag 11 oktober 2015 @ 18:42:
Heb je je php pool herstart, of enkel nginx?

Ik wist niet dat ik php apart moest herstarten, kan het zijn dat ik met de webserver die ik gebruikte voordat ik over stapte naaar Nginx dit niet hoefde te doen? Dat was Lighttpd met php5-cgi of cli, of fcgi (Weet het niet meer precies maar was niet fpm) Volgens hoefde ik daar alleen de webserver maar te reloaden or restarten.

In ieder geval,
/etc/init.d/php5-fpm restart
Heeft het opgelost.

Bedankt guys, het werkt nu!

[azerty]

KeRaNoZ schreef op zondag 11 oktober 2015 @ 23:03:
[...]


[...]


Ik wist niet dat ik php apart moest herstarten, kan het zijn dat ik met de webserver die ik gebruikte voordat ik over stapte naaar Nginx dit niet hoefde te doen? Dat was Lighttpd met php5-cgi of cli, of fcgi (Weet het niet meer precies maar was niet fpm) Volgens hoefde ik daar alleen de webserver maar te reloaden or restarten.

In ieder geval,
/etc/init.d/php5-fpm restart
Heeft het opgelost.

Bedankt guys, het werkt nu!

Dat kan perfect zijn.

Echter is het zo dat Nginx eigenlijk niet meer dan een soort van "doorgeefluik" is in het geval van php. Nginx serveert de statische bestanden, maar voor php leest het eigenlijk enkel maar het resultaat uit en geeft dat terug. Vandaar ook dat php (fpm in dit geval) volledig losstaat van Nginx.

Nu ja, het is tenminste opgelost

[keranoz]

azerty schreef op zondag 11 oktober 2015 @ 23:07:
[...]


Dat kan perfect zijn.

Echter is het zo dat Nginx eigenlijk niet meer dan een soort van "doorgeefluik" is in het geval van php. Nginx serveert de statische bestanden, maar voor php leest het eigenlijk enkel maar het resultaat uit en geeft dat terug. Vandaar ook dat php (fpm in dit geval) volledig losstaat van Nginx.

Nu ja, het is tenminste opgelost

Dan ga ik eens even een keer uitzoeken wat nou het verschil is tussen cgi, fcgi, cli en fpm. En waarom fpm wel een restart moet hebben maar dat dat bij fcgi bijvoorbeeld (volgens mij) niet hoeft.

[azerty]

KeRaNoZ schreef op zondag 11 oktober 2015 @ 23:54:
[...]


Dan ga ik eens even een keer uitzoeken wat nou het verschil is tussen cgi, fcgi, cli en fpm. En waarom fpm wel een restart moet hebben maar dat dat bij fcgi bijvoorbeeld (volgens mij) niet hoeft.

Kijk ook eens hoe nginx werkt, dat zal volgens mij ook wel al een deel verklaren hoor

[McKaamos]

azerty schreef op maandag 12 oktober 2015 @ 00:14:
[...]


Kijk ook eens hoe nginx werkt, dat zal volgens mij ook wel al een deel verklaren hoor

In dit geval is t gewoon PHP-FPM.
PHP-FPM is een vorm van CGI (Common Gateway Interface).
Die draai je als daemon/systeemservice.
De managerthread beheert meerdere workerthreads en bepaalt de config die ze gebruiken.
Omdat de managerthread constant draait, zal deze gereload moeten worden om een config aanpassing door te voeren.

PHP onder Apache (en ik vermoed dan ook Lighttpd) werkt als plugin module van Apache. Elke keer dat er een aanvraag komt voor een PHP-based pagina, wordt er een PHP child-thread gespawned door Apache.
En elke keer wordt ook de config geladen.
Zit wat meer overhead aan vast en is inherent trager dan FPM.

Apache kan je ook wel inrichten met PHP als CGI/FastCGI trouwens, maar dat is niet default.

Oh, en om meteen te beantwoorden wat CLI is: dat is Command Line Interface.
Die gebruik je als je PHP gebruikt voor commandline scripts. Wordt ook bij elke aanvraag appart gestart en dus ook elke keer met verse reload van de config.

[ Voor 11% gewijzigd door McKaamos op 12-10-2015 00:24 ]

[keranoz]

McKaamos schreef op maandag 12 oktober 2015 @ 00:22:
[...]

In dit geval is t gewoon PHP-FPM.
PHP-FPM is een vorm van CGI (Common Gateway Interface).
Die draai je als daemon/systeemservice.
De managerthread beheert meerdere workerthreads en bepaalt de config die ze gebruiken.
Omdat de managerthread constant draait, zal deze gereload moeten worden om een config aanpassing door te voeren.

PHP onder Apache (en ik vermoed dan ook Lighttpd) werkt als plugin module van Apache. Elke keer dat er een aanvraag komt voor een PHP-based pagina, wordt er een PHP child-thread gespawned door Apache.
En elke keer wordt ook de config geladen.
Zit wat meer overhead aan vast en is inherent trager dan FPM.

Apache kan je ook wel inrichten met PHP als CGI/FastCGI trouwens, maar dat is niet default.

Oh, en om meteen te beantwoorden wat CLI is: dat is Command Line Interface.
Die gebruik je als je PHP gebruikt voor commandline scripts. Wordt ook bij elke aanvraag appart gestart en dus ook elke keer met verse reload van de config.

azerty schreef op maandag 12 oktober 2015 @ 00:14:
[...]


Kijk ook eens hoe nginx werkt, dat zal volgens mij ook wel al een deel verklaren hoor

Dank voor de info, en zal ik doen!