104: Réinitialisation de la connexion par le pair lors de la lecture de l'en-tête de réponse en amont (Nginx)

Question

104: Réinitialisation de la connexion par le pair lors de la lecture de l'en-tête de réponse en amont (Nginx)

Demandé el 5 de Octobre, 2013: Quand la question a-t-elle été
273309 affichage: Nombre de visites la question a
5 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

J'ai un serveur qui fonctionnait bien jusqu'au 3 octobre 2013 à 10h50 quand il a commencé à renvoyer de manière intermittente des erreurs "502 Bad Gateway" au client.

Environ 4 requêtes sur 5 réussissent mais environ 1 sur 5 échouent avec un 502.

Le journal d'erreur de nginx contient des centaines de ces erreurs;

2013/10/05 06:28:17 [error] 3111#0: *54528 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.75, server: www.bec-components.co.uk  request: ""GET /?_n=Fridgefreezer/Hotpoint/8591P;_i=x8078 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.bec-components.co.uk"

Cependant, le journal d'erreurs PHP ne contient pas d'erreurs correspondantes.

Y a-t-il un moyen d'obtenir de PHP plus d'informations sur la raison pour laquelle il réinitialise la connexion?

Ceci est nginx.conf;

user              www-data;
worker_processes  4;
error_log         /var/log/nginx/error.log;
pid               /var/run/nginx.pid;

events {
   worker_connections  1024;
}

http {
  include          /etc/nginx/mime.types;
  access_log       /var/log/nginx/access.log;

  sendfile               on;
  keepalive_timeout      30;
  tcp_nodelay            on;
  client_max_body_size   100m;

  gzip         on;
  gzip_types   text/plain application/xml text/javascript application/x-javascript text/css;
  gzip_disable "MSIE [1-6]\.(?!.*SV1)";

  include /gvol/sites/*/nginx.conf;

}

Et ceci est le .conf de ce site;

server {

  server_name   www.bec-components.co.uk bec3.uk.to bec4.uk.to bec.home;
  root          /gvol/sites/bec/www/;
  index         index.php index.html;

  location ~ \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires        2592000;   # 30 jours
    log_not_found  off;
  }

  ## Déclencher le téléchargement pour les fichiers '.xml' au lieu de les afficher.
  location ~ \.xml$ {
    add_header Content-disposition "attachment; filename=$1";
  }

   location ~ \.php$ {
      fastcgi_read_timeout  3600;
      include               /etc/nginx/fastcgi_params;
      keepalive_timeout     0;
      fastcgi_param         SCRIPT_FILENAME  $document_root$fastcgi_script_name;
      fastcgi_pass          127.0.0.1:9000;
      fastcgi_index         index.php;
   }
}

## bec-components.co.uk ##
server {
   server_name   bec-components.co.uk;
   rewrite       ^/(.*) http://www.bec-components.co.uk$1 permanent;
}

Demandé el 5 de Octobre, 2013 par Wim ten Brink

0 votes

Qu'est-ce qui a été modifié ce jour-là? Avez-vous mis à jour votre application ou PHP? Quelle est votre application? Avez-vous activé le débogage dans php-fpm?

Commenté el 5 de Octobre, 2013 par Pothi Kalimuthu

0 votes

Rien n'a été modifié ce jour-là. La configuration du serveur n'a pas été modifiée, ni aucun script PHP. Ce n'est pas un problème d'espace disque. Mon application est juste un ensemble de scripts PHP. Je n'utilise pas php-fpm, je lance simplement php-fastcgi en utilisant php-cgi -b 127.0.0.1:9000. Cela fonctionnait sans problème depuis 3 ans. Je ne comprends pas pourquoi ce problème est apparu.

Commenté el 5 de Octobre, 2013 par Wim ten Brink

0 votes

J'ai récemment eu un problème similaire où nginx se plaignait d'une réinitialisation de connexion par un homologue tout en lisant l'en-tête de réponse en amont, dans mon cas, c'était uWSGI qui était le vrai problème, redémarrer uWSGI a résolu le problème pour moi, quant à savoir pourquoi cela se produisait, c'est une autre question.

Commenté el 26 de Janvier, 2014 par Ilari Scheinin

Afficher 1 autres commentaires

Answer 1

5 Réponses

Answer 2

31voto

that guy from over there Points 1345

Je ferais toujours confiance si mes serveurs web me disaient 502 Bad Gateway.

Quel est le temps de disponibilité de votre processus FastCGI/NGINX?
Surveillez-vous les connexions réseau?
Pouvez-vous confirmer/nier un changement dans le nombre de visiteurs autour de ce jour-là?

Ce que signifie l'erreur

Votre processus FastCGI n'est pas accessible par NGINX; soit trop lent soit totalement incompatible. Une passerelle incorrecte signifie que NGINX ne peut pas compléter l'étape fastcgi_pass vers les ressources définies écoutant localhost:9000 et à ce moment très spécifique.

Vos journaux d'erreurs initiaux disent tout :

recv() failed 
    -> nginx a échoué

(104: Connection reset by peer) while reading response header from upstream, 
    -> pas de réponse complète, ou pas de réponse du tout
upstream: "fastcgi://127.0.0.1:9000", 
    -> qui est-il, qui a échoué???

De mon point de vue limité, je suggère :

De redémarrer votre processus FastCGI ou serveur
De vérifier votre access.log
D'activer le debug.log

Répondu el 6 de Octobre, 2013 par that guy from over there (1345 Points )

2 votes

D'accord. Que me disent mes serveurs web?

Commenté el 31 de Mars, 2014 par Wim ten Brink

1 votes

Voir ma modification (qu'est-ce que cela signifie)

Commenté el 31 de Mars, 2014 par that guy from over there

2 votes

Je vois, donc la Gateway dans ce cas est le serveur PHP. Merci.

Commenté el 31 de Mars, 2014 par Wim ten Brink

Afficher 1 autres commentaires

Answer 3

20voto

Morgan Points 31

Je sais que ce sujet est ancien, mais il continue de resurgir de temps en temps, donc, à la recherche de réponses sur le web, j'ai trouvé les trois possibilités suivantes :

Une erreur de programmation provoque parfois un segfault de php-fpm, ce qui signifie à son tour que la connexion avec nginx sera interrompue. Cela laisse généralement quelques journaux et/ou des coredumps, qui peuvent être analysés plus en détail.
Pour une raison quelconque, PHP n'arrive pas à écrire un fichier de session (généralement : session.save_path = "/var/lib/php/sessions"). Cela peut être dû à des autorisations incorrectes, une mauvaise propriété, un mauvais utilisateur/groupe, ou des problèmes plus ésotériques/obscurs comme une épuisement des inodes dans ce répertoire (ou même un disque plein !). Cela ne laissera généralement pas beaucoup de coredumps et éventuellement pas grand-chose dans les journaux d'erreurs PHP.
Encore plus difficile à déboguer : une extension se comporte mal (frappant occasionnellement une sorte de limite interne, ou un bug qui n'est pas déclenché tout le temps), provoquant un segfault et faisant tomber le processus php-fpm avec elle, fermant ainsi la connexion avec nginx. Les coupables habituels sont APC, memcache/d, etc. (dans mon cas, c'était l'extension New Relic), donc l'idée ici est de désactiver chaque extension jusqu'à ce que l'erreur disparaisse.

Répondu el 6 de Juin, 2016 par Morgan (31 Points )

1 votes

+1 En ce qui me concerne, c'était une erreur de programmation.

Commenté el 6 de Septembre, 2016 par Nimbuz

1 votes

Nous avons rencontré cette erreur et la désactivation de l'extension PHP New Relic APM a révélé une erreur plus spécifique qui nous a permis de localiser le problème : [29-Jan-2018 16:47:48 UTC] Erreur fatale PHP : La taille mémoire autorisée de 805306368 octets a été dépassée (tentative d'allocation de 262144 octets) dans vendor/magento/module-configurable-product/Pricing/Price/Con‌figurableRegularPric‌e.php à la ligne 142 [29-Jan-2018 16:47:48 UTC] Erreur fatale PHP : La taille mémoire autorisée de 805306368 octets a été dépassée (tentative d'allocation de 323584 octets) dans Inconnu à la ligne 0 Je suppose que New Relic a coincé sur le chemin "Inconnu".

Commenté el 29 de Janvier, 2018 par Ramandeep Singh

1 votes

Dans mon cas, le code provoquait une erreur de segmentation, en supprimant une ligne à la fois, j'ai obtenu cette confirmation.

Commenté el 31 de Mai, 2021 par Herz3h

Answer 4

11voto

Mahdir Points 41

Rencontré également ce problème. Je l'ai résolu en augmentant la limite de mémoire opcache, si vous l'utilisez (remplacement de APC). Il semble que PHP-FPM coupe les connexions chaque fois que le cache est trop plein. C'est aussi la raison pour laquelle la réponse de shgnInc résout le problème temporairement.

Donc, trouvez le fichier /etc/php5/fpm/php.ini (ou l'équivalent dans votre distribution) et augmentez la memory_consumption au niveau requis par votre site. Désactiver opcache peut également fonctionner.

[opcache]
opcache.memory_consumption = 196

Répondu el 2 de Février, 2017 par Mahdir (41 Points )

0 votes

Comment désactiver opcache ?

Commenté el 6 de Août, 2021 par João Pimentel Ferreira

0 votes

@JoãoPimentelFerreira opcache.enable = 0 dans php.ini le ferait

Commenté el 16 de Janvier, 2024 par user145632

Answer 5

6voto

shgnInc Points 1574

Dans mon cas de même problème, je redémarre simplement le service php-fpm et le problème est résolu.

sudo service php5-fpm restart

Ou parfois ce problème survient en raison d'un grand nombre de demandes. Par défaut, le pm.max_requests dans php5-fpm est peut-être de 100 ou moins.

Pour le résoudre, augmentez sa valeur en fonction des demandes de votre site, par exemple 500.

Ensuite, vous devez redémarrer le service.

Répondu el 26 de Octobre, 2015 par shgnInc (1574 Points )

Answer 6

3voto

Vasiliy Points 121

Dans mon cas, la désactivation de l'extension xdebug a aidé.

Répondu el 3 de Octobre, 2017 par Vasiliy (121 Points )

0 votes

Pareil, dans mon cas j'ai défini une condition pour un point d'arrêt et à ce moment-là j'ai désactivé le point d'arrêt, l'erreur a disparu.

Commenté el 16 de Avril, 2019 par roman204

104: Réinitialisation de la connexion par le pair lors de la lecture de l'en-tête de réponse en amont (Nginx)

Réponses

Ce que signifie l'erreur

Questions en vedette

Top Tags

SistemesEz.com

Powered by:

104: Réinitialisation de la connexion par le pair lors de la lecture de l'en-tête de réponse en amont (Nginx)

Réponses

Ce que signifie l'erreur

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

Powered by: