Ich stelle auf meinem CI/CD-Linux-Rechner (mit 16.04.4 LTS + Gitlab CI im Docker-Container) ein sehr seltsames Verhalten fest und suche nach einem „Debug-Pfad“ für das Problem. Und das Problem ist, dass der Container meines Gitlab CI nach jedem Neustart nicht gestartet werden kann, da Port 443 (den er verwenden soll) nicht verfügbar ist. Netstat zeigt:
~$ netstat -ano | grep 443
tcp6 0 0 :::443 :::* LISTEN off (0.00/0/0)
Ich habe versucht, zu verwenden fuser, tcpkillund habe noch viele weitere Lösungen gefunden. Keine davon hat tatsächlich funktioniert. Es sieht so aus, als ob es immer von PID 1 verwendet wird.
Aber dann habe ich mich für die Ausführung entschieden nmap 127.0.0.1, was mir Folgendes zeigte:
~$ 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
Und danach... wurde der Port frei - die zweite Ausführung dieses Befehls zeigt:
~$ 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
Wie ist das überhaupt möglich, dass nmapein belegter Port freigegeben werden kann? Es funktioniert jedes Mal.
Ich bin sehr neugierig, warum das passiert, weiß aber nicht, „wo“ ich mit dem Debuggen beginnen soll. Oder ist es vielleicht ein allgemeines Problem, aber ich kann einfach keine Beschreibung dafür finden?
Antwort1
Haben Sie die Systemprotokolle auf Ihrem Ubuntu-Host überprüft? Sie können den journalctlBefehl zu diesem Zweck verwenden. Ein möglicher Grund, der mir einfällt, istSocket-Aktivierungwobei systemd (das als PID 1 ausgeführt wird) auf dem Port lauscht und einen Prozess startet, wenn etwas (z. B. nmap) versucht, eine Verbindung damit herzustellen.
Um diese Theorie zu testen, könnten Sie beispielsweise neu starten und ausführen journalctl -fzuFFolgen Sie den Protokollen und führen Sie nmap erneut in einer anderen Shell aus.
Neben der Überprüfung der Protokolle können Sie auch systemctlherausfinden systemctl status, welche Dienste gestartet wurden oder fehlgeschlagen sind.
Schließlich ist es auch durchaus möglich, dass ein Dienst aufgrund fehlender Abhängigkeiten früher im Bootvorgang nicht gestartet werden konnte. Wenn Ihr Dienst beispielsweise von Docker abhängt, dies aber nicht (implizit) als solches deklariert, kann der erste Versuch, ihn beim Booten zu starten, fehlschlagen, während ein manueller Start mit etwas Glück funktionieren kann, da Docker bereits gestartet wurde.
Antwort2
@Lekensteyn, danke! Deine Antwort hat mich zur Lösung geführt.
Da es anderen mit ähnlichen Problemen helfen könnte, habe ich Folgendes getan:
~$ systemctl list-units --state=failed
Dies hat gezeigt, dass es 4 ausgefallene Dienste gibt (die nicht mehr verwendet werden, einige davon sind Legacy-Lösungen).
Dann als Root:
~# systemctl stop <a_failed_service_name> && systemctl disable <a_failed_service_name>
für jede ausgefallene Einheit ausgeführt.
Nach dem Neustart ist Port 443 frei.