bug: Kill aborts cleanup when OCI spec omits network namespace

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

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

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
68/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go, linux
領域
backend, operating-systems

調査の方向性

unikontainers パッケージから始めて、Kill()、joinSandboxNetNs()、findNS() の場所を特定し、既存の回帰テスト TestKill_MissingNetworkNamespace を確認します。ネットワーク namespace が存在しない場合にどのように Kill() へ到達するかを追跡し、vmm.Stop() と network.CleanupAllUruncTaps() を含むクリーンアップ経路を検証します。完了の条件は、ネットワーク namespace のない有効な OCI 仕様でも必要なクリーンアップに到達し、一方で本当に致命的な namespace エラーは区別可能なままであることです。

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

説明

bug Core

Description

Kill() aborts before reaching the VMM and network cleanup when the OCI specification does not contain a network namespace.

When linux.namespaces omits specs.NetworkNamespace, findNS() returns:

namespace network was not found

This error propagates through joinSandboxNetNs() to Kill(), which returns immediately instead of continuing with the VMM and network cleanup.

This means the cleanup path is skipped for this OCI configuration.

System info

  • urunc version/commit: b752cf9
  • Architecture: amd64
  • OS: Linux
  • Go: 1.26.4
  • VMM: Not exercised in the reproduction environment
  • Unikernel: Not exercised in the reproduction environment

Steps to reproduce

  1. Create an OCI specification whose linux.namespaces contains namespaces such as pid, ipc, uts, and mount, but omits the network namespace.
  2. Construct a Unikontainer using this OCI specification.
  3. Invoke Unikontainer.Kill().
  4. Observe the returned error and whether the cleanup functions are reached.

A minimal regression-style test reproduces the behavior:

=== RUN   TestKill_MissingNetworkNamespace
--- PASS: TestKill_MissingNetworkNamespace (0.00s)
PASS
ok      github.com/urunc-dev/urunc/pkg/unikontainers    0.003s

The test verifies that Kill() returns:

failed to join sandbox netns: namespace network was not found

and that the VMM stop function is not invoked.

Actual behavior

Kill() returns:

failed to join sandbox netns: namespace network was not found

before reaching the subsequent cleanup operations.

The relevant control flow is:

Kill()
  -> joinSandboxNetNs()
      -> findNS(..., specs.NetworkNamespace)
          -> namespace network was not found
  -> return error

Therefore the subsequent cleanup calls are not reached:

vmm.Stop(u.State.Pid)
network.CleanupAllUruncTaps()

The reproduction confirms:

Kill() return value: error
VMM.Stop() called: NO
Network cleanup called: NO

Expected behavior

If an OCI specification legitimately omits the network namespace, Kill() should still perform the required process/VMM cleanup instead of aborting before cleanup.

At minimum, absence of the namespace should not prevent the termination/cleanup path from being executed.

Root cause

findNS() returns an error when the requested namespace type is absent from the OCI namespace list:

namespace network was not found

joinSandboxNetNs() does not distinguish between an intentionally absent network namespace and other namespace lookup failures, so the error propagates to Kill().

Kill() then returns immediately and does not reach the VMM/network cleanup operations.

Testing

A temporary regression-style test was used to verify the behavior.

The test does not claim to demonstrate an actual orphaned QEMU/Firecracker process because a complete VMM/container lifecycle could not be exercised in the available environment.

The confirmed behavior is that Kill() returns before vmm.Stop() and network.CleanupAllUruncTaps() are invoked.

Relevance to robustness testing

This is an OCI edge case that can be exercised by structured testing/fuzzing by mutating the namespace configuration.

A robustness test suite should verify that lifecycle operations such as Kill() continue to perform required cleanup across valid and edge-case OCI configurations.

Possible fix direction

Investigate handling an absent network namespace separately from an invalid/unusable namespace.

The fix should avoid relying on matching an error string and should preserve genuinely fatal namespace errors.

A regression test should verify that a Unikontainer without a network namespace does not abort the cleanup path.

Related issues

I searched the existing urunc issues and pull requests for:

  • Kill
  • NetworkNamespace
  • network namespace
  • joinSandboxNetNs
  • namespace was not found
  • cleanup

Issue #240 is related to Kill() cleanup behavior but covers a different failure mode and does not address the missing network namespace case.

主要言語
Go
スター
308
フォーク
222
平均マージ
2日 12時間
マージ済み PR（30日）
42

環境構築

はじめの一歩

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

urunc-dev/urunc のほかの issue

urunc-dev/urunc の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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