%20pero%20no%20hay%20nada%20m%C3%A1s%20escuchando%20en%20el%20puerto.png)
Estoy tratando de resolver esto desde hace casi 6 meses. El problema está presente de forma aleatoria independientemente de la versión de Nginx o Ubuntu. El paquete nginx-extras se utiliza desde los repositorios de Ubuntu. Este es un grupo de 10 servidores con hardware diferente que tienen el mismo problema.
En resumen: Nginx no podrá recargarse aleatoriamente. El registro de errores revelará que no se pudo vincular a la dirección (lo que actualmente ocurre en el puerto 443, pero también ocurre aleatoriamente en el puerto 80). A veces, la emisión service nginx upgraderecargará el servidor. Si eso también falla, service nginx restarta veces funcionará y otras no. Cuando incluso esto falla, la única forma de recargar la configuración es emitir service nginx stop, esperar unos segundos y luego hacerlo service nginx start. Ninguno de estos comandos devolverá jamás un error, en lugar de hacerlo, lo harían [OK]incluso cuando el comando falle.
Detener e iniciar Nginx es un problema ya que estas máquinas envían archivos grandes y las transferencias se interrumpen. Además, si se extrae un archivo grande del backend para almacenarlo en caché, durante el reinicio la versión almacenada en caché terminará corrompiéndose.
nginx version: nginx/1.4.6 (Ubuntu)
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
TLS SNI support enabled
configure arguments:
--with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
--prefix=/usr/share/nginx
--conf-path=/etc/nginx/nginx.conf
--http-log-path=/var/log/nginx/access.log
--error-log-path=/var/log/nginx/error.log
--lock-path=/var/lock/nginx.lock
--pid-path=/run/nginx.pid
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi
--with-debug
--with-pcre-jit
--with-ipv6
--with-http_ssl_module
--with-http_stub_status_module
--with-http_realip_module
--with-http_addition_module
--with-http_dav_module
--with-http_flv_module
--with-http_geoip_module
--with-http_gzip_static_module
--with-http_image_filter_module
--with-http_mp4_module
--with-http_perl_module
--with-http_random_index_module
--with-http_secure_link_module
--with-http_spdy_module
--with-http_sub_module
--with-http_xslt_module
--with-mail
--with-mail_ssl_module
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/headers-more-nginx-module
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-auth-pam
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-cache-purge
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-dav-ext-module
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-development-kit
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-echo
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/ngx-fancyindex
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-http-push
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-lua
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-upload-progress
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/nginx-upstream-fair
--add-module=/build/nginx-hzyca8/nginx-1.4.6/debian/modules/ngx_http_substitutions_filter_module
Proceso actualmente en ejecución:
# ps ax | grep nginx
25771 pts/1 S+ 0:00 grep --color=auto nginx
29145 ? S 0:00 nginx: master process /usr/sbin/nginx
29664 ? RN 516:47 nginx: worker process
29665 ? SN 513:46 nginx: worker process
29666 ? SN 514:17 nginx: worker process
29667 ? SN 517:24 nginx: worker process
29668 ? SN 512:29 nginx: worker process
29669 ? SN 515:28 nginx: worker process
29670 ? SN 517:52 nginx: worker process
29671 ? SN 507:52 nginx: worker process
29672 ? S 0:13 nginx: cache manager process
Intentando recargar:
# service nginx reload
* Reloading nginx configuration nginx [ OK ]
Mirando la salida de ps nuevamente, no pasó nada:
# ps ax | grep nginx
29145 ? S 0:00 nginx: master process /usr/sbin/nginx
29664 ? SN 516:54 nginx: worker process
29665 ? SN 513:49 nginx: worker process
29666 ? SN 514:20 nginx: worker process
29667 ? SN 517:27 nginx: worker process
29668 ? SN 512:34 nginx: worker process
29669 ? SN 515:31 nginx: worker process
29670 ? SN 518:08 nginx: worker process
29671 ? SN 507:55 nginx: worker process
29672 ? S 0:13 nginx: cache manager process
31121 pts/1 S+ 0:00 grep --color=auto nginx
Una verificación en el registro de errores (dirección IP redactada):
2018/03/10 00:22:29 [info] 32481#0: Using 32768KiB of shared memory for push module in /etc/nginx/nginx.conf:95
2018/03/10 00:22:29 [emerg] 29145#0: bind() to 195.181.160.xx:443 failed (98: Address already in use)
2018/03/10 00:22:29 [emerg] 29145#0: bind() to 195.181.160.xx:443 failed (98: Address already in use)
2018/03/10 00:22:29 [emerg] 29145#0: bind() to 195.181.160.xx:443 failed (98: Address already in use)
2018/03/10 00:22:29 [emerg] 29145#0: bind() to 195.181.160.xx:443 failed (98: Address already in use)
2018/03/10 00:22:29 [emerg] 29145#0: bind() to 195.181.160.xx:443 failed (98: Address already in use)
2018/03/10 00:22:29 [emerg] 29145#0: still could not bind()
El único proceso que utiliza 443 es el propio nginx:
# sudo netstat -tulpn | grep :443
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 29145/nginx
En estos servidores, cada cliente tiene dos bloques de servidores: uno público, que escucha en puertos estándar, y otro interno que realiza el almacenamiento en caché. Este último escucha en una IP de host local, en un puerto único y se accede a través de proxy_pass desde el bloque público. Estos bloques internos bloquean todos los proxy_pass a otras ubicaciones. Las razones de esta configuración son demasiado complejas para cubrirlas aquí.
¿Qué he comprobado hasta ahora?
Todos los bloques internos pueden resolver sus aguas arriba.
Todos los puertos internos son únicos y no están siendo utilizados por otros servicios.
SPDY no se utiliza (se encontró un error informado en la lista de correo de Nginx)
El problema parece aleatorio, pero es más probable que ocurra cuanto más tiempo se haya ejecutado una instancia de Nginx
Comportamiento presente tanto en Ubuntu 14.04.X como en 16.04, versiones de Nginx 1.4.6 a la última.
No hay relación obvia con la carga de CPU, disco o red
Bloques de servidor de ejemplo, generados automáticamente por la plataforma que utiliza estos servidores (alguna información redactada):
Bloque público:
server {
keepalive_timeout 10;
listen 195.xx.xx.xx:80;
#listen 195.xx.xx.xx:80 ssl;
root /home/nginx;
server_name xxxxxx.xxxxxx.com ;
index index.php index.html index.htm index.nginx-debian.html
error_page 403 /403.html; location = /403.html {
return https://www.xxxxxx.com/403.php;
}
error_page 404 /404.html; location = /404.html {
return https://www.xxxxxx.com/404.php;
}
error_page 500 /500.html; location = /500.html {
root /home/nginx;
}
location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
return 301 http://xxxxx.xxxxxxx.com$request_uri;
}
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header geo_xxxxx $geoip_country_code;
proxy_intercept_errors on;
proxy_buffering off;
proxy_pass http://127.0.1.3:8213;
set $sent_http_accept_ranges bytes;
}
location ~ /playlist.m3u8 {
secure_link $arg_st,$arg_e;
secure_link_md5 xxxxxxxxxxxxxxxxxxxx$uri$remote_addr$arg_e;
if ($secure_link = "") { return 403; }
if ($secure_link = "0") { return 410; }
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header geo_xxxxxx $geoip_country_code;
proxy_intercept_errors on;
proxy_buffering off;
proxy_pass http://127.0.1.3:8213;
}
#ssl_certificate /etc/letsencrypt/live//fullchain.pem; # managed by Certbot
#ssl_certificate_key /etc/letsencrypt/live//privkey.pem; # managed by Certbot
#include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
limit_rate 10000k;
}
Bloque privado asociado:
proxy_cache_path /home/nginx/282-281-cache levels=1:2
keys_zone=282-281:5m inactive=48h max_size=500g;
limit_conn_zone $http_x_forwarded_for zone=addr282-281:10m;
map $http_user_agent $blockedUA {
default 0;
"~thisisadummyua" 1;
"~thisisanotherdummyua" 1;
}
map $http_referer $blockedREF {
default 0;
"~thisisadummyref.com" 1;
"~thisisanotherdummyref.com" 1;
}
server {
limit_conn addr282-281 100;
limit_conn_status 429;
keepalive_timeout 10;
listen 127.0.1.3:8213;
root /home/nginx;
server_name 127.0.1.3;
location ~* \.(m3u8)$ {
real_ip_header X-Forwarded-For;
set_real_ip_from xxx.xx.xx.xx/xx;
proxy_set_header geo_xxxxx $geoip_country_code;
proxy_set_header Host $proxy_host;
real_ip_recursive on;
# CORS setup
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Expose-Headers' 'Content-Length';
proxy_ignore_headers Cache-Control;
add_header Cache-Control public;
# allow CORS preflight requests
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain charset=UTF-8';
add_header 'Content-Length' 0;
return 204;
}
add_header Edge-Cache $upstream_cache_status;
proxy_cache 282-281;
proxy_cache_valid 200 206 5s;
proxy_cache_use_stale error timeout invalid_header updating
http_500 http_502 http_503 http_504;
proxy_cache_lock on;
proxy_cache_lock_timeout 10s;
proxy_cache_key $uri;
proxy_pass http://xxx.xx.xx.xx:41000;
}
location / {
deny 10.10.10.1;
deny 10.10.10.2;
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Expose-Headers' 'Content-Length';
proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
proxy_ignore_headers Set-Cookie;
add_header Cache-Control public;
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain charset=UTF-8';
add_header 'Content-Length' 0;
return 204;
}
real_ip_header X-Forwarded-For;
set_real_ip_from xxx.xx.xx.xx/xx;
proxy_set_header geo_xxxxx $geoip_country_code;
proxy_set_header Host $proxy_host;
proxy_http_version 1.1;
real_ip_recursive on;
proxy_set_header Range $http_range;
proxy_set_header If-Range $http_if_range;
proxy_no_cache $http_range $http_if_range;
proxy_cache_bypass $http_range $http_if_range;
proxy_temp_path /home/nginx/282-281-temp;
proxy_buffering on;
proxy_max_temp_file_size 25m;
proxy_intercept_errors on;
proxy_cache_purge PURGE from all;
add_header Edge-Cache $upstream_cache_status;
proxy_cache 282-281;
proxy_cache_valid 200 206 5m;
proxy_cache_use_stale error timeout invalid_header updating
http_500 http_502 http_503 http_504;
proxy_cache_lock on;
proxy_cache_lock_timeout 120s;
proxy_cache_key $uri;
proxy_pass http://xxx.xx.xx.xx:41000/;
}
if ($blockedUA = 1){
return https://www.xxxxxxx.com/403.php;
}
#if ($http_user_agent = "") {
# return https://www.xxxxxxx.com/403.php;
#}
if ($blockedREF = 1){
return https://www.xxxxxxx.com/403.php;
}
access_log /var/log/nginx/xxxx/xxx-xxx-proxy-access.log xxxx;
error_log /var/log/nginx/xxxx/xxx-xxx-proxy-error.log;
}`
Ahora estoy considerando probar el paquete nginx-common, pero estos son sistemas de producción. No estoy seguro de si el problema se manifestaría en una máquina de prueba.
EDITAR: Después de hacer esta pregunta, decidí agregar un trabajo cron para recargar cada 3 horas, ya que mis observaciones fueron que es más probable que el problema se manifieste cuanto más tiempo se ejecute Nginx sin recargar. Es el tercer día hoy con el cron ejecutándose y todos los servidores responden a las recargas correctamente y el problema aún no se ha observado en ninguno de ellos. En el mejor de los casos, esto no es más que una curita y no resuelve el problema real. Sin embargo, es lo mejor que se me ha ocurrido y prácticamente lo único que parece funcionar.
EDITAR2: Agregar un cron no solucionó el problema, pero tuve que intentarlo. Luego compilé Nginx desde el código fuente con la menor cantidad de módulos con los que podemos trabajar y lo instalé en uno de los servidores. Esto fue hace 7 días y este servidor no ha tenido problemas desde entonces. Como el tiempo me apremia, hace 3 días decidí no esperar más y comencé a eliminar los servidores de producción uno a la vez para reemplazar su Nginx con la versión recién compilada. Hasta ahora todo bien y ninguno de ellos muestra signos del problema. Esperemos no volver para una tercera edición.
Respuesta1
Esto ocurre de vez en cuando. Así que no tiene nada de especial.
Establecimos el siguiente enfoque, si queremos reiniciar o recargar nuestros servicios:
1. Verifique si la configuración funciona como se esperaba:
nginx -t
2. Reinicie Nginx y verifique la respuesta:
service nginx restart
3. Si no fue posible reiniciar debido a una colisión de puertos...
Compruebe qué servicio está bloqueando el puerto:
netstat -nltp | grep -E ':80\W|:443\W'
Matar el servicio correspondiente:
killall nginx
En algunos casos, es posible que un proceso esté congelado. Tienes que acabar con el proceso de colgar con más poder:
kill -9 {process_id}