Bonjour,
Nous avons un serveur chez OVH avec l'offre PRO. Serveur sur lequel nous avons déployé une application web en React + Symfony.
Depuis peu, (le serveur a 2 ans), certaines de nos entités deviennent inaccessible (erreur 500) sans raison.
Exemple une entité Client parmi plein d'autres.
Ceci uniquement sur le server OVH et avec Symfony en mode prod.
Nous avons exporté la base de donnée et réimporté la base en local en mettant le mode production, il n'y a aucun problème sur cette même entité.
Si nous passons le serveur en mode dev, l'erreur disparait et donc nous n'avons pas l'erreur précise.
Aucun log n'atteint le fichier de log. Mais si nous créons une erreur 500 volontairement dans le code, celle-ci est bien loggée.
Le seul fichier de log qu'OVH nous propose, par rapport à un serveur que nous maitriserions, c'est celui assez pauvre dans Statiques et Logs.
Il ne nous donne que :
(104)Connection reset by peer: AH10143: FastCGI: comm with server "{path}" aborted: read failed, refer {url de l'id du client}
Le client en question est une entité assez légère et celui-ci est peu rempli. Il n'y a pas de dépassement de ressources dans "Statistiques de l'infrastructure".
De plus, la base de donnée ne fait que 10Mo sur les 2Go disponible
La question du manque de puissance du serveur par un : "Fatal error: Allowed memory size of ... bytes exhausted (tried to allocate ... bytes". Parait assez peu probable car nous sommes ici sur une entité qui a pour l'instant peut de jointure et qui ici ne sont même pas requêtées. De plus, cela n'arrive pas sur d'autres Clients.
Passer à une offre supérieur est envisageable, mais vu les données et l'utilisation du site, cela ne devrait pas être nécessaire.
L'assitance OVH n'est bonne à rien et ne sert qu'à envoyer paître ceux qui leur ouvre un ticket...
Quelqu'un a-t-il déjà résolu ce problème sans avoir à changer d'hébergeur ?
Hébergements Web - Mutu, offre PRO, Symfony, Connection reset by peer: AH10143: FastCGI: comm with server
Related questions
- Connexion à mon compte client
149257 
13.02.2019 09:51
- Serveur non sécurisé, celui-ci ne supporte pas FTP sur TLS
124030 03.09.2018 14:46
- reCAPTCHA erreur pour le propriétaire du site : clé de site non valide
108581 14.02.2019 16:17
- [FAQ] Comment mettre à jour mon site pour supporter Apache 2.4 ?
96000 28.07.2017 11:39
- Passage en php 7.4
94947 30.06.2020 05:05
- Augmenter taille PHP Post Max Size sur mutualisé ?
89202 04.12.2019 21:52
- The requested URL / was not found on this server
88520 02.03.2017 18:25
- NextCloud sur mutualisé
88289 07.04.2017 08:42
- Deploy d'un projet Node JS
88205 12.10.2016 20:18
- Ce site est inaccessible Impossible de trouver l'adresse DNS du serveur
87974 16.10.2016 16:24
Bonjour @MildredD2,
Quel est le nom de domaine concerné?
^FabL
Bonjour,
myfacturation.com
Désactiver le fichier de configuration de cache doctrine de symfony par défaut retire l'erreur.
Retirer l'utilisation du cache est très rarement une bonne chose.
Utiliser chmod 777 -R sur le var/cache/ ne change rien.
Symfony propose une gestion des droits du cache : https://symfony.com/doc/current/setup/file_permissions.html
```sh
HTTPDUSER=$(ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1)
sudo setfacl -dR -m u:"$HTTPDUSER":rwX -m u:$(whoami):rwX var
sudo setfacl -R -m u:"$HTTPDUSER":rwX -m u:$(whoami):rwX var
```
Les commandes suivantes sont proposées. Je ne suis pas sûr que cela résoudrait le problème vu que 777 ne résout rien, mais on ne peut pas essayer nous n'avons pas les droits suffisant pour installer setfacl sur un mutu.
Downgrade la version "doctrine/orm" de 2.12 à 2.9, résout le problème. A partir de la version 2.10 de doctrine, la dépendance supporte le PSR-6 de PHP à propos des normes du "Caching interface".
Peut-être que les serveurs OVH ne respectent pas ces normes (spécifiques) et cela créer des incompatibilité ? Du fait qu'avec nos serveurs de test locaux, nous n'avons pas le problème.
Source : https://github.com/doctrine/DoctrineBundle/issues/1433
La source suggère aussi que cela puisse venir de la version 7.4 de PHP.