Encontrei um comportamento muito estranho em minha máquina CI/CD Linux (executando 16.04.4 LTS + Gitlab CI no contêiner Docker) e estou procurando um "caminho de depuração" para o problema. E o problema é que após cada reinicialização, o contêiner do CI do Gitlab não pode ser iniciado, por causa da porta 443 (que deveria ser usada). Netstat mostra:
~$ netstat -ano | grep 443
tcp6 0 0 :::443 :::* LISTEN off (0.00/0/0)
Tentei usar fusere tcpkillmuitas outras soluções que encontrei. Nenhum deles funcionou na verdade. Parece que está sempre em uso pelo PID 1.
Mas então resolvi executar o nmap 127.0.0.1, que me mostrou:
~$ 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
E depois disso... a porta ficou livre - a segunda execução deste comando mostra:
~$ 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
Como isso é possível, nmapconseguir liberar uma porta ocupada? Funciona sempre.
Estou muito curioso para saber por que isso está acontecendo, mas não sei "por onde" começar minha depuração. Ou talvez seja um problema comum, mas simplesmente não consigo encontrar nenhuma descrição disso?
Responder1
Você verificou os logs do sistema no seu host Ubuntu? Você pode usar o journalctlcomando para essa finalidade. Uma razão potencial em que consigo pensar éativação de soqueteonde o systemd (que roda como PID 1) escuta na porta e inicia um processo quando algo (como nmap) tenta se conectar a ela.
Para testar esta teoria, você poderia, por exemplo, reiniciar e executar journalctl -fparafSiga os logs e execute o nmap novamente em um shell diferente.
Além de verificar os logs, você também pode executar systemctlou systemctl statusdescobrir quais serviços foram iniciados ou falharam.
Finalmente, também é totalmente possível que um serviço tenha falhado ao iniciar no início do processo de inicialização devido à falta de dependências. Por exemplo, se o seu serviço depende do Docker, mas não o declara (implicitamente) como tal, a tentativa inicial de iniciá-lo na inicialização poderá falhar, enquanto uma inicialização manual poderá funcionar por sorte, uma vez que o Docker já foi iniciado.
Responder2
@Lekensteyn, obrigado! Sua resposta me levou à solução.
Como pode ajudar alguém com problema semelhante, o que eu fiz:
~$ systemctl list-units --state=failed
Isso mostrou que existem 4 serviços com falha (que não estão mais em uso, alguma solução legada).
Então, como root:
~# systemctl stop <a_failed_service_name> && systemctl disable <a_failed_service_name>
executado para cada unidade com falha.
Após a reinicialização, a porta 443 fica livre.