`nerdctl kill -s <signal>` removes the network of a container that continues to run

オープン
  • 何か問題がありますか？
#5,327 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@papidb がすでに取り組んでいます。

2026年11月5日 から。

  • #5328 @papidb による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go
領域
cli, networking

調査の方向性

Start with pkg/cmd/container/kill.go and trace how Kill, cleanupNetwork, and killContainer handle signal and task status; compare the stop signal behavior with SIGKILL. Check the related issue #5323 for context, then run the container kill tests and reproduce the SIGHUP case with the steps in this report. Done means non-stopping signals preserve networking and health checks, while failed kills on stopped containers leave the network allocation intact.

索引モデルが issue の本文から書いたものです。

説明

Description

nerdctl kill removes the network of the container for every signal, not only for signals that stop the container. When the signal does not stop the container (for example SIGHUP to reload nginx), the container continues to run without its network setup:

  1. Published ports stop working.
  2. The IP address goes back to the IPAM pool. A new container can then get the same IP address while the first container still uses it.
Steps to reproduce the issue
sudo nerdctl run -d --name lab-hup -p 127.0.0.1:18080:80 --ip 10.4.0.240 nginx:alpine
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:18080   # 200

sudo nerdctl kill -s SIGHUP lab-hup
sudo nerdctl inspect lab-hup --format '{{.State.Status}}'          # running
curl -s -o /dev/null -w '%{http_code}\n' --max-time 3 http://127.0.0.1:18080   # 000
sudo ls /var/lib/cni/networks/bridge/10.4.0.240                    # No such file or directory

sudo nerdctl run -d --name lab-dup --ip 10.4.0.240 alpine sleep infinity   # succeeds
sudo nerdctl exec lab-hup ip -4 -o addr show eth0                  # 10.4.0.240/24
sudo nerdctl exec lab-dup ip -4 -o addr show eth0                  # 10.4.0.240/24
Describe the results you received and expected

Expected

A signal that does not stop the container does not change its network. The published port continues to work. The IP address stays allocated, so nerdctl run --ip 10.4.0.240 fails for a second container.

Received

After kill -s SIGHUP:

Check Result
Container status running
HTTP on the published port no response (000)
CNI lease file for 10.4.0.240 removed
Second container with --ip 10.4.0.240 starts, and both containers have 10.4.0.240
Cause

In pkg/cmd/container/kill.go, Kill calls cleanupNetwork before killContainer, for all signals. cleanupNetwork calls cni.Remove, which removes the port forwards and releases the IP address. The function does not check the signal or the task status.

The same order has a second effect. When the container is not running, cleanupNetwork runs first, and then killContainer fails with container is not running. The command fails, but the IP address is already released.

healthcheck.RemoveTransientHealthCheckFiles in killContainer also runs for every signal. So after kill -s SIGHUP, the container may continue to run without its health check. I did not test this part.

Possible fix
  1. Check the task status before cleanupNetwork. If the container is not running, return the error and do not change the network.
  2. Call cleanupNetwork only when the signal is SIGKILL or the stop signal of the container (SIGTERM by default).

With step 2, kill -s SIGTERM on a container that ignores SIGTERM still removes the network. That is the current behavior, and nerdctl stop has the same risk.

What version of nerdctl are you using?

main at dc841ac6. The result is the same with the fix for #5323 applied.

Host information
  • containerd v2.4.1, runc 1.5.2, rootful
  • Ubuntu 24.04, kernel 6.8, aarch64
  • Network: default bridge

Related: #5323. In that issue, nerdctl also releases the network at the wrong time. The fix for #5323 does not change this behavior.

主要言語
Go
スター
10.5k
フォーク
839
平均マージ
3日 18時間
マージ済み PR（30日）
40

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

containerd/nerdctl のほかの issue

containerd/nerdctl の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。