5 votes

nginx enregistre la sortie stderr de php-fpm coupée à des positions apparemment aléatoires

Depuis que j'ai commencé à utiliser une bibliothèque PHP qui produit une longue chaîne d'appels, il est de plus en plus difficile de déboguer les problèmes causés par cette bibliothèque, car mes journaux d'erreurs finissent par contenir des messages comme celui-ci : (certaines valeurs ont été supprimées en utilisant * )

2017/08/23 10:47:26 [error] 13057#13057: *206119 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught ActiveRecord\DatabaseException: PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid input syntax for integer: "" in /var/www/********/vendor/php-activerecord/php-activerecord/lib/Connection.php:337
Stack trace:
#0 /var/www/********/vendor/php-activerecord/php-activerecord/lib/Connection.php(337): PDOStatement->execute(Array)
#1 /var/www/********/vendor/php-activerecord/php-activerecord/lib/Table.php(237): ActiveRecord\Connection->query('SELECT * FROM "...', Array)
#2 /var/www/********/vendor/php-activerecord/php-activerecord/lib/Table.php(219): ActiveRecord\Table->find_by_sql('SELECT * FROM "...', Array, false, NULL)
#3 /var/www/********/vendor/php-activerecord/php-activerecord/lib/Model.php(1666): ActiveRecord\Table->find(Array)
#4 /var/www/********/vendor/php-activerecord/php-activerecord/lib/Model.php(1605): ActiveRecord\Model::find_by_pk('', Array)
#5 /var/www/********/includes/classes/Models/NSModel.php(11): ActiveRecord\Model::find(''" while reading response header from upstream, client: **.***.***.***, server: ***********, request: "POST /************************************ HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.1-fpm.sock:", host: "***********", referrer: "************************************************************"

Remarquez comment, sur la dernière ligne, la sortie FastCGI stderr s'arrête brusquement après ActiveRecord\Model::find(''" . Un autre exemple :

2017/08/22 17:20:53 [error] 13057#13057: *193907 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught TypeError: Argument 1 passed to App\DeviantArt::isImageAvailable() must be of the type string, null given, called in /var/www/********/includes/classes/ImageProvider.php on line 138 and defined in /var/www/********/includes/classes/DeviantArt.php:357
Stack trace:
#0 /var/www/********/includes/classes/ImageProvider.php(138): App\DeviantArt::isImageAvailable(NULL)
#1 /var/www/********/includes/classes/ImageProvider.php(21): App\ImageProvider->setUrls('*******')
#2 /var/www/********/includes/classes/Posts.php(207): App\ImageProvider->__construct('******************', Array)
#3 /var/www/********/includes/classes/Controllers/PostController.php(334): App\Posts::checkRequestFinishingImage('***************...')
#4 /var/www/********/includes/classes/RouteHelper.php(11): App\Controllers\PostController->action(Array)
#5 /var/www/********/includes/do.php(27): App\RouteHelper::App\{closure}(Array)
#6 /var/www/********/www/index.php(1): require('/var/www/******...')
#7 {main}
  t" while reading response header from upstream, client: **.***.***.***, server: ***********, request: "POST /*************************** HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.1-fpm.sock:", host: "***********"

Ici, la sortie stderr est coupée après l'exécution de la fonction t ce qui laisse suffisamment d'informations pour trouver le problème, mais ce n'est toujours pas le message complet. Je ne trouve pas de modèle entre la longueur de la sortie et le moment où elle est coupée.

J'utilise nginx version 1.10.3 et PHP version 7.1.8 sur Debian Stretch. J'ai également essayé de définir les valeurs suivantes dans nginx.conf (parce que j'ai cherché des solutions à ce problème dans le passé), mais les exemples ci-dessus ont été produits avec ces paramètres déjà en vigueur.

fastcgi_buffers 256 4k;
client_max_body_size 20M;

-1voto

SeinopSys Points 502

D'après les réponses trouvées sous un question similaire même si je parvenais à contourner les limites de caractères de php-fpm, nginx tronquerait également la sortie, ce qui pourrait entraîner une perte d'informations.

Pour éliminer complètement ce risque, j'ai opté pour l'utilisation de Monologue pour gérer la journalisation au niveau de l'application, qui peut être utilisée avec une sortie de fichier pour écrire des messages d'erreur et des traces de pile arbitrairement longs. Cette question pourrait être utile à quiconque cherche à faire de même.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X