Pourquoi est-ce que j'obtiens une erreur Apache Proxy 503?

Question

Mon serveur a été bien jusqu'à hier. C'était sous Redmine, et il était le plus heureux des petits serveur jusqu'à ce que mon "ami" importé une table SQL que mon petit gars n'a pas pu prendre. Malheureusement, après une heure d'essayer d'obtenir le ptit gars pour répondre, nous avons dû cycle d'alimentation lui.

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

À l'aide de Lynx sur le serveur (http://localhost:8000) vous pouvez voir le Rubis de travail sur l'application de l'amende. Mais ce bit n'est pas de travail dans mon fichier de configuration d'Apache:

<VirtualHost *:80>
    ServerName sub.example.com
    ProxyPass / http://localhost:8000
    ProxyPassReverse / http://localhost:8000
    ProxyPreserveHost on
    LogLevel debug
</VirtualHost>

Voici le log d'erreur de sortie 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: trouvé travailleur http://localhost:8000 pour http://localhost:8000/
[debug] mod_proxy.c(756): l'Exécution du régime de gestionnaire http (tentative de 0)
[debug] mod_proxy_http.c(1687): proxy: HTTP: portion de l'URL http://localhost:8000/
[debug] proxy_util.c(1755): proxy: HTTP: a acquis connexion (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: fam 2 socket créé pour vous connecter à localhost

[erreur] (13)de refus d'Autorisation: proxy: HTTP: tentez de vous connecter à l'adresse 127.0.0.1:8000 (localhost) a échoué
[erreur] ap_proxy_connect_backend la désactivation de travailleur (localhost)

[debug] proxy_util.c(1773): proxy: HTTP: a publié connexion (localhost)

Answer 1

Apache va répondre avec 503 du pour au moins 60 secondes une fois qu'il détecte que le serveur principal est en panne. C'est le comportement par défaut. Comme dans votre exemple, si vous redémarrez votre serveur d'arrière-plan (Rails dans cet exemple) et que quelqu'un tente d'accéder à travers le proxy Apache avant de Rails est prêt Apache renverra 503 pour les prochaines 60 secondes, peu importe si votre backend est maintenant "up". Consultez l'apache docs sur la directive ProxyPass, où il est dit:

nouvelle tentative de 60

Le pool de connexion de travailleur réessayer délai d'attente en secondes. Si le pool de connexion travailleur au serveur cible est dans l'état d'erreur d'Apache de ne pas transmettre les demandes à ce serveur jusqu'à l'expiration de ce délai. Ceci permet d'arrêter le serveur d'arrière-plan pour l'entretien, et de le mettre en ligne plus tard. Une valeur de 0 signifie toujours réessayer travailleurs dans un état d'erreur pas de délai d'attente.

Donc, si vous réglez votre Proxy Pass pour inclure retry=0, vous ne verrez pas le 503 est lorsque vous redémarrez votre service principal. Ceci est également utile lorsque vous utilisez Apache comme proxy inverse au cours du développement! Par exemple:

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

Answer 2

Exécuter la commande suivante

 # /usr/sbin/setsebool httpd_can_network_connect 1
 

OU

 # /usr/sbin/setsebool httpd_can_network_connect true
 

et après cela, redémarrez httpd

 # service httpd restart
 

Answer 3

Êtes-vous sûr qu'ils sont de redémarrer dans le bon ordre? J'ai eu des problèmes bizarres où Apache démarre, puis Mongrel commence et bien que Métis est en cours d'exécution, Apache jette toujours l'erreur du proxy.

J'ai résolu ce problème dans le passé avec diverses incantations et redémarre Apache et, finalement, les dieux sont heureux. Il semble que, parfois, la Mongrel processus de ne pas se fermer correctement de sorte que vous devez manuellement les tuer. Voici un lien avec quelques [possible] de l'aide.

J'ai fini par l'ajout d'un "kill" pour ma /etc/init.d/ mongrel script parce qu'il s'est passé beaucoup de choses. - Il s'arrêter Mongrel, tué tous les Bâtards sessions, a commencé Métis et redémarré Apache.

<snip>
    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=$?
  ;;
</snip>

Probablement pas une très bonne solution, mais le mal s'en alla.

Answer 4

Essayez d'exécuter monit pour surveiller vos bâtards derrière Apache, et de cette façon, il peut redémarrer les bâtards pour eux s'ils meurent ou ont trop faim pour la mémoire. Si, pour une raison quelconque, Apache est toujours confus, il se peut que vous deviez simplement redémarrer Apache avec élégance et qu'il devrait se résoudre lui-même, mais pour 99% des cas, la surveillance de vos bâtards devrait éviter que cela ne se reproduise. L'autre option est de regarder dans Phusion Passenger.

Answer 5

Pour que cela fonctionne, j'ai dû désactiver SELinux, puis ajouter des barres obliques de fin aux lignes "localhost: 8000".

Voici le code pour désactiver SELinux:

 echo 0 >/selinux/enforce