Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: intercept.php erreur 503 |l ighttpd php-fpm [ Répondre ] Par : Richard REY (Rexy) on 2023-03-10 22:15 | [forum:623734] |
|
Bonjour, J'espère que ce réglage fera disparaître le phénomène constaté. Si je résume : Paramètre valeur par défaut valeur modifiée pm dynamic dynamic pm.max_children 35 256 pm.start_servers 20 64 pm.min_spare_servers 5 16 pm.max_spare_servers 35 64 Si vous confirmez que dans le cas d'un réseau dense cela règle le problème, on pourrait imaginer un option de l'ACC qui permette de basculer d'une config "light" à une config "heavy". |
|
| RE: intercept.php erreur 503 |l ighttpd php-fpm [ Répondre ] Par : Cristi T on 2023-03-09 14:59 | [forum:623731] |
|
Bonjour, merci @Rexy pour le retour. - Ressources disponibles : je pense que ce n'est pas le problème, nous avons une machine avec 8 coeurs / 16 threads constants à 1%, 64Go de RAM, 500Go SSD en RAID 6 et une connexion 10Gbits/s symétrique. - Un client bavard : Je suis en train d'analyser le fichier access.log mais globalement rien d'anormal, les requêtes viennent majoritairement du refresh de l'acc (admin) et des still_connected.php pour les users qui laissent la page status.php ouverte. Notre serveur est en place depuis plusieurs années, c'est étrange que le problème se présente aussi subitement et de façon répétitive sur 72h. --- La situation est "stable" depuis 24h, nous avons modifié la configuration de php-fpm dans le fichier /etc/php-fpm.d/www.conf : pm = dynamic pm.max_children = 256 pm.start_servers = 64 pm.min_spare_servers = 16 pm.max_spare_servers = 64 Puis redémarrage du service. C'est un peu plus gourmand en RAM mais notre serveur le supporte facilement. Nous vous tenons informés de l'avancement de nos recherches. |
|
| RE: intercept.php erreur 503 |l ighttpd php-fpm [ Répondre ] Par : Richard REY (Rexy) on 2023-03-08 23:02 | [forum:623728] |
|
Bonsoir, Nous n'avons pour l'instant pas d'autres retour de ce type. La théorie : " Une erreur HTTP 503 se produit quand un serveur ne peut fournir les ressources demandées lors de la requête du client". Ainsi, j'investiguerai dans 2 directions : - ressources disponibles pour ALCASAR (mémoire vive / espace disque / débit réseau) - un client un peu trop "bavard" (flooding pour faire un déni de service) Bon courage pour la recherche. Tenez-nous informé |
|
| intercept.php erreur 503 |l ighttpd php-fpm [ Répondre ] Par : Cristi T on 2023-03-08 14:15 | [forum:623726] |
|
Bonjour à tous, Depuis lundi 06/03/23 vers 9h, nous avons un problème sur notre alcasar : Une erreur 503 empêche les clients d'accéder à l'interface d'authentification et donc de se connecter à internet. Impossible également pour les administrateurs d'accéder à l'acc. En regardant les logs, nous nous sommes rendus comptes que les deux erreurs suivantes revenaient en permanence : cat /var/log/lighttpd/error.log => 2023-03-06 08:58:46: (mod_openssl.c.1712) SSL: -1 5 104 Connection reset by peer 2023-03-06 08:58:47: (mod_fastcgi.c.421) FastCGI-stderr: PHP message: PHP Notice: Undefined index: O in /var/www/html/index.php on line 67 En redémmarant lighttpd + php-fpm, l'intercept refonctionne pendant quelques secondes... puis même problème. Même chose après une réinstallation du paquet php-fpm. Nous avons profiter de la situation pour faire une migration d'alcasar en 3.6. L'installation s'est bien passée et l'ensemble des services étaient de nouveau fonctionnels. --- Deux jours plus tard (ce matin), le même problème se produit : Impossible d'accéder à l'interface d'authentification et à l'acc. Après quelques minutes, timeout : erreur 503. Notre alcasar tourne sur un KVM. Nous avons rollback sur la sauvegarde faite après l'installation d'alcasar 3.6 (qui était fonctionnel donc). Le problème était toujours présent. En regardant les logs, nous voyons des erreurs similaires : cat /var/log/lighttpd/error.log 2023-03-08 09:26:21: mod_fastcgi.c.487) FastCGI-stderr:PHP message: PHP Warning: Undefined array key "O" in /var/www/html/index.php on line 6 => 2023-03-08 09:26:21: mod_openssl.c.3095) SSL: 1 error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac => 2023-03-08 09:26:22: mod_openssl.c.3095) SSL: 1 error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac 2023-03-08 09:26:22: gw_backend.c.315) gw-server re-enabled: unix:/var/lib/php-fpm/php-fpm.sock 0 /var/lib/php-fpm/php-fpm.sock 2023-03-08 09:26:47: gw_backend.c.238) establishing connection failed: socket: unix:/var/lib/php-fpm/php-fpm.sock: Resource temporarily unavailable 2023-03-08 09:26:47: gw_backend.c.970) all handlers for /intercept.php?res=notyet&uamip=10.10.0.1&uamport=3990&challenge=[...] on .php are down. cat /var/log/php-fpm/php-fpm.log [08-Mar-2023 09:20:12] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 2 idle, and 25 total children [08-Mar-2023 09:20:13] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 16 children, there are 4 idle, and 28 total children [08-Mar-2023 09:20:14] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 3 idle, and 29 total children [08-Mar-2023 09:20:15] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 0 idle, and 31 total children [08-Mar-2023 09:20:16] WARNING: [pool www] server reached pm.max_children setting (35), consider raising it Nous avons émis et installé de nouveaux certificats SSL : mêmes erreurs. Lorsque les clients sont authentifiés ou s'ils sont autorisés par MAC, l'accès à internet fonctionne correctement. Pour que notre établissement passe en fonctionnement dégradé, nous avons activé le mode bypass. En l'activant, l'acc et l'intercept redevienne accessible (il y a peut être moins de requêtes http vers alcasar ?) Est-ce que certains d'entre vous constatent également ce problème ? |
|
