moto - apache tomcat
¿Por qué recibo un error Apache Proxy 503? (7)
¿Estás seguro de que están reiniciando en el orden correcto? He tenido problemas extraños en los que se inicia Apache, luego se inicia Mongrel y, aunque Mongrel se está ejecutando, Apache aún arroja el error de proxy.
He resuelto esto en el pasado con varios conjuros y reinicios de Apache y, finalmente, los dioses están felices. Parece que a veces los procesos de Mongrel no se cierran correctamente, así que tienes que matarlos manualmente. Aquí hay un link con algo de [posible] ayuda.
Terminé agregando una opción "matar" a mi script /etc/init.d/ mongrel porque sucedió mucho. Se detiene Mongrel, mató a todas las sesiones de Mongrel, inició Mongrel y reinició 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>
Probablemente no sea una solución muy buena, pero el mal se fue.
Mi servidor estaba funcionando bien hasta ayer. Estaba ejecutando Redmine , y era el servidor más feliz hasta que mi "amigo" importó una tabla SQL que mi pequeño no podía tomar. Desafortunadamente, después de una hora de tratar de hacer que el tipo lil respondiera, tuvimos que darle un ciclo a él.
Ahora, después del reinicio, obtenemos un error 503 cuando intentamos visitar el dominio conectado a Redmine. Está conectado a un daemon Mongrel , y usamos Apache Proxy para dirigir todas las conexiones al puerto en el que Redmine se está ejecutando.
Usando Lynx en el servidor ( http://localhost:8000 ) puede ver que la aplicación Ruby funciona bien. Pero este bit no funciona en mi archivo de configuración de Apache:
<VirtualHost *:80>
ServerName sub.example.com
ProxyPass / http://localhost:8000
ProxyPassReverse / http://localhost:8000
ProxyPreserveHost on
LogLevel debug
</VirtualHost>
Aquí está la salida del registro de errores para 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: found worker http://localhost:8000 for http://localhost:8000/ [debug] mod_proxy.c(756): Running scheme http handler (attempt 0) [debug] mod_proxy_http.c(1687): proxy: HTTP: serving URL http://localhost:8000/ [debug] proxy_util.c(1755): proxy: HTTP: has acquired connection for (localhost) [debug] proxy_util.c(1815): proxy: connecting http://localhost:8000/ to localhost:8000 [debug] proxy_util.c(1908): proxy: connected / to localhost:8000 [debug] proxy_util.c(2002): proxy: HTTP: fam 2 socket created to connect to localhost [error] (13)Permission denied: proxy: HTTP: attempt to connect to 127.0.0.1:8000 (localhost) failed [error] ap_proxy_connect_backend disabling worker for (localhost) [debug] proxy_util.c(1773): proxy: HTTP: has released connection for (localhost)
Apache responderá con 503 durante al menos 60 segundos cada vez que detecte que el servidor de fondo está inactivo. Este es el comportamiento predeterminado. Como en su ejemplo, si reinicia su servidor back-end (Rails en este ejemplo) y alguien intenta acceder a él a través del proxy Apache antes de que Rails esté listo, Apache devolverá los 503 durante los próximos 60 segundos independientemente de si su servidor ahora está ''activo'' . Consulte los documentos de Apache en ProxyPass donde dice:
reintentar 60
El tiempo de espera de reintentos del empleado de la agrupación de conexiones en segundos. Si el trabajador del grupo de conexión al servidor back-end está en el estado de error, Apache no reenviará ninguna solicitud a ese servidor hasta que expire el tiempo de espera. Esto permite cerrar el servidor backend para mantenimiento y volver a ponerlo en línea más adelante. Un valor de 0 significa siempre reintentar a los trabajadores en un estado de error sin tiempo de espera.
Por lo tanto, si configura su Proxy Pass para que incluya retry = 0, no verá los 503 cuando reinicie su servicio back-end. ¡Esto también es útil cuando se usa Apache como proxy inverso durante el desarrollo! Por ejemplo:
ProxyPass / http: // localhost: 8000 retry = 0
Ejecuta el siguiente comando
# /usr/sbin/setsebool httpd_can_network_connect 1
O
# /usr/sbin/setsebool httpd_can_network_connect true
y luego de eso reiniciar httpd
# service httpd restart
Fist, debes instalar selinux : (SELinux significa Security-Enhanced Linux.)
apt-get install selinux
Después de eso, puede habilitar la Política de Seguridad de SElinux siguiendo el siguiente comando:
sed -i ''s/SELINUX=.*/SELINUX=permissive/'' /etc/selinux/config
Darse cuenta:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
¡Final, reinicia apache!
Intenta ejecutar Monit para monitorear a tus conejos detrás de Apache, y de esa manera puede reiniciar mordrels para ti si mueren o si tienen demasiada hambre para la memoria. Si por alguna razón Apache aún se confunde, puede que tenga que reiniciar apache y debería resolverse solo, pero para el 99% de los casos tener Monit vigilando a sus mestizos debería evitar que esto vuelva a ocurrir. La otra opción es buscar en Phusion Passenger.
Para que esto funcione, necesitaba activar SELinux y luego agregar barras diagonales a las líneas "localhost: 8000".
Aquí está el código para desactivar SELinux:
echo 0 >/selinux/enforce
Primero compruebe si el puerto 8080 está escuchando o no con el siguiente comando
netstat -tlpn
Si no es así, reinicia el servidor jenkins con el siguiente comando
sudo /etc/init.d/jenkins start
Debería funcionar ahora. Espero eso ayude.