Pourquoi est-ce que je reçois une erreur Apache Proxy 503?

Mon serveur se portait bien jusqu’à hier. Il utilisait Redmine , et c’était le petit serveur le plus heureux jusqu’à ce que mon “ami” ait importé une table SQL que mon petit gars ne pouvait pas prendre. Malheureusement, au bout d’une heure d’essayer de faire réagir le gars, nous devions le rallumer.

Maintenant, après le redémarrage, nous obtenons une erreur 503 lorsque vous essayez de visiter le domaine connecté à Redmine. Il est connecté à un démon Mongrel et nous utilisons Apache Proxy pour diriger toutes les connexions vers le port sur lequel Redmine est exécuté.

En utilisant Lynx sur le serveur ( http://localhost:8000 ), vous pouvez voir que l’application Ruby fonctionne correctement. Mais ce bit ne fonctionne pas dans mon fichier de configuration Apache:

  ServerName sub.example.com ProxyPass / http://localhost:8000 ProxyPassReverse / http://localhost:8000 ProxyPreserveHost on LogLevel debug

Voici la sortie du journal des erreurs pour Apache:

 [debug] mod_proxy_http.c (54): proxy: HTTP: canonicalising URL // localhost: 8000
 [debug] proxy_util.c (1335): [client 216.27.137.51] proxy: http: fichier de travail trouvé http: // localhost: 8000 pour http: // localhost: 8000 /
 [debug] mod_proxy.c (756): gestionnaire http du schéma en cours d'exécution (tentative 0)
 [debug] mod_proxy_http.c (1687): proxy: HTTP: URL de service http: // localhost: 8000 /
 [debug] proxy_util.c (1755): proxy: HTTP: connexion acquise pour (localhost)
 [debug] proxy_util.c (1815): proxy: connexion http: // localhost: 8000 / à localhost: 8000
 [debug] proxy_util.c (1908): proxy: connecté / à localhost: 8000
 [debug] proxy_util.c (2002): proxy: HTTP: socket fam 2 créé pour se connecter à localhost

 [erreur] (13) Autorisation refusée: proxy: HTTP: tentative de connexion à 127.0.0.1:8000 (localhost) a échoué
 [erreur] ap_proxy_connect_backend désactivant worker pour (localhost)

 [debug] proxy_util.c (1773): proxy: HTTP: a libéré la connexion pour (localhost)

Apache répondra avec 503 pendant au moins 60 secondes chaque fois qu’il détecte que le serveur principal est en panne. Ceci est le comportement par défaut. Comme dans votre exemple, si vous redémarrez votre serveur principal (Rails dans cet exemple) et que quelqu’un essaie d’y accéder via le proxy Apache avant que Rails ne soit prêt, Apache renvoie 503 pour les 60 prochaines secondes, peu importe . S’il vous plaît voir les docs apache sur ProxyPass où il indique:

réessayez 60

Délai d’attente du nouvel utilisateur du pool de connexions en secondes. Si l’agent du pool de connexions sur le serveur principal est dans l’état d’erreur, Apache ne transmettra aucune demande à ce serveur avant l’expiration du délai. Cela permet d’arrêter le serveur principal pour la maintenance et de le remettre en ligne plus tard. Une valeur de 0 signifie toujours réessayer les travailleurs dans un état d’erreur sans délai d’attente.

Donc, si vous définissez votre Proxy Pass pour inclure retry = 0, vous ne verrez pas les 503 lorsque vous redémarrez votre service backend. Ceci est également utile lorsque vous utilisez Apache comme proxy inverse lors du développement! Par exemple:

ProxyPass / http: // localhost: 8000 retry = 0

Exécuter la commande suivante

 # /usr/sbin/setsebool httpd_can_network_connect 1

 # /usr/sbin/setsebool httpd_can_network_connect true

et après ce redémarrage httpd

 # service httpd restart

Êtes-vous sûr qu’ils redémarrent dans le bon ordre? J’ai eu des problèmes étranges au démarrage d’Apache, puis Mongrel démarre et même si Mongrel est en cours d’exécution, Apache lance toujours l’erreur proxy.

J’ai résolu cela par le passé avec diverses incantations et redémarrages d’Apache et finalement les dieux sont heureux. Il semble que parfois les processus Mongrel ne s’arrêtent pas correctement et vous devez donc les supprimer manuellement. Voici un lien avec une aide [possible].

J’ai fini par append une option “kill” à mon script /etc/init.d/ parce que cela se produisait tellement. Il arrête Mongrel, tue toutes les sessions de Mongrel, lance Mongrel et redémarre Apache.

  kill) echo "Stopping, killing, starting, and restarting Apache..." mongrel_cluster_ctl stop -c $CONF_DIR --clean killall -u mongrel mongrel_cluster_ctl start -c $CONF_DIR --clean /etc/init.d/httpd restart RETVAL=$? ;;

Probablement pas une très bonne solution mais le mal est parti.

Essayez de lancer monit pour surveiller vos métis derrière Apache, et de cette façon, il peut redémarrer les méta-sons pour eux s’ils meurent ou s’ils ont trop faim de mémoire. Si pour une raison quelconque, Apache est toujours confus, il se peut que vous ayez à redémarrer correctement Apache, qui devrait se résoudre, mais dans 99% des cas, le suivi de vos métis ne devrait plus se produire. L’autre option est de regarder Phusion Passenger.

Vérifiez d’abord si le port 8080 écoute ou non par la commande suivante

 netstat -tlpn

Sinon, redémarrez le serveur jenkins par la commande suivante

 sudo /etc/init.d/jenkins start

Cela devrait fonctionner maintenant. J’espère que cela aide.

Fist, vous devez installer selinux : (SELinux signifie Security-Enhanced Linux.)

 apt-get install selinux

Après cela, vous pouvez activer la stratégie de sécurité de SElinux en suivant la commande suivante:

 sed -i 's/SELINUX=.*/SELINUX=permissive/' /etc/selinux/config

Remarquer:

 # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded.

Finale, redémarrez apache!

Pour que cela fonctionne, je devais activer SELinux, puis append des barres obliques sur les lignes “localhost: 8000”.

Voici le code pour désactiver SELinux:

 echo 0 >/selinux/enforce