Encuentro un comportamiento muy extraño en mi máquina CI/CD Linux (ejecutando 16.04.4 LTS + Gitlab CI en un contenedor Docker) y estoy buscando una "ruta de depuración" para el problema. Y el problema es que después de cada reinicio, el contenedor de mi Gitlab CI no puede iniciarse debido al puerto 443 (que se supone que debe usar). Netstat muestra:
~$ netstat -ano | grep 443
tcp6 0 0 :::443 :::* LISTEN off (0.00/0/0)
Intenté usarlo fusery tcpkillencontré muchas más soluciones. Ninguno de ellos funcionó en realidad. Parece que siempre está en uso por el PID 1.
Pero luego decidí ejecutar nmap 127.0.0.1, lo que me mostró:
~$ nmap 127.0.0.1
Starting Nmap 7.01 ( https://nmap.org ) at 2019-03-18 09:31 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00015s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
443/tcp open https
5900/tcp open vnc
Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
Y después de eso... el puerto quedó libre - la segunda ejecución de este comando muestra:
~$ nmap 127.0.0.1
Starting Nmap 7.01 ( https://nmap.org ) at 2019-03-18 09:31 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00016s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
5900/tcp open vnc
Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds
¿Cómo es posible esto, que nmappueda liberar un puerto ocupado? Funciona todo el tiempo.
Tengo mucha curiosidad por saber por qué sucede esto, pero no sé "dónde" comenzar la depuración. ¿O tal vez es un problema común, pero no puedo encontrar ninguna descripción del mismo?
Respuesta1
¿Ha revisado los registros del sistema en su host Ubuntu? Puede utilizar el journalctlcomando para este propósito. Una posible razón que se me ocurre esactivación del enchufedonde systemd (que se ejecuta como PID 1) escucha en el puerto e inicia un proceso cuando algo (como nmap) intenta conectarse a él.
Para probar esta teoría, podría, por ejemplo, reiniciar y journalctl -fejecutarFSiga los registros y ejecute nmap nuevamente en un shell diferente.
Además de verificar los registros, también puede ejecutar systemctlo systemctl statusaveriguar qué servicios se iniciaron o fallaron.
Finalmente, también es muy posible que un servicio no se haya iniciado antes en el proceso de arranque debido a que faltan dependencias. Por ejemplo, si su servicio depende de Docker pero no lo declara (implícitamente) como tal, entonces el intento inicial de iniciarlo en el arranque podría fallar, mientras que un inicio manual podría funcionar por suerte, ya que Docker ya se inició.
Respuesta2
@Lekensteyn, ¡gracias! Tu respuesta me llevó a la solución.
Como puede ayudar a alguien con un problema similar, lo que hice:
~$ systemctl list-units --state=failed
Esto demostró que hay 4 servicios fallidos (que ya no están en uso, alguna solución heredada).
Entonces, como raíz:
~# systemctl stop <a_failed_service_name> && systemctl disable <a_failed_service_name>
ejecutado por cada unidad fallida.
Después del reinicio, el puerto 443 queda libre.