CI/CD Linux マシン (Docker コンテナで 16.04.4 LTS + Gitlab CI を実行) で非常に奇妙な動作が発生し、問題の「デバッグ パス」を探しています。問題は、再起動するたびに Gitlab CI のコンテナがポート 443 (使用することになっているポート) のために起動できないことです。Netstat には次のように表示されます。
~$ netstat -ano | grep 443
tcp6 0 0 :::443 :::* LISTEN off (0.00/0/0)
を使用しようとしましたがfuser、tcpkill他にも多くの解決策が見つかりました。実際にはどれも機能しませんでした。常に PID 1 で使用されているようです。
しかし、その後、 を実行することに決めましたnmap 127.0.0.1。その結果、次のことが示されました。
~$ 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
そしてその後...ポートは解放されました - このコマンドの 2 回目の実行では次のように表示されます:
~$ 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
nmapビジー状態のポートを解放できるのは一体どうしたら可能なのでしょうか? 毎回動作します。
なぜこのようなことが起こるのか非常に興味がありますが、デバッグを「どこから」開始すればよいのかわかりません。あるいは、これはよくある問題かもしれませんが、その説明が見つからないだけなのでしょうか?
答え1
Ubuntuホストのシステムログを確認しましたか？journalctlこの目的にはコマンドを使用できます。考えられる理由の1つはソケットのアクティベーションここで、systemd (PID 1 として実行) はポートをリッスンし、何か (nmap など) がポートに接続しようとするとプロセスを開始します。
この理論をテストするには、例えば再起動しjournalctl -fてふログに従って、別のシェルで nmap を再度実行します。
ログを確認する以外に、systemctlまたはを実行してsystemctl status、どのサービスが開始されたか、または失敗したかを確認することもできます。
最後に、依存関係が不足しているために、起動プロセスの早い段階でサービスが起動に失敗する可能性も十分にあります。たとえば、サービスが Docker に依存しているが、それを (暗黙的に) 宣言していない場合、起動時にサービスを起動する最初の試行は失敗する可能性がありますが、Docker がすでに起動されているため、手動での起動は運よく機能する可能性があります。
答え2
@Lekensteyn、ありがとう！あなたの回答のおかげで解決策が見つかりました。
同様の問題を抱えている他の人の役に立つかもしれないので、私がやったことは次のとおりです。
~$ systemctl list-units --state=failed
これにより、失敗したサービスが 4 つあることが示されました (これらはもう使用されていない、レガシー ソリューションです)。
次に、root として次の操作を実行します。
~# systemctl stop <a_failed_service_name> && systemctl disable <a_failed_service_name>
障害が発生したユニットごとに実行されます。
再起動後、ポート 443 は解放されます。