入力を探しています。ネットワーク名前空間の有効期限に関連する次の観察は予想されますか、それともエラーとして報告する必要がありますか？
- プロセスが開いている場合は、
/proc/<pid>/net/devファイルが閉じられるまで他のプロセスの名前空間の有効期限をブロック/遅延できます。そのためには、その名前空間の一部である必要はありません。
これは非常に驚くべき行動のようです。これにより、ローカルユーザーは適切なファイルにアクセスしてprocネットワークネームスペースの veth インターフェイスの破損を遅延/防止できます。ファイルを閉じずに開く欠陥のある監視ツール/procもこの問題を引き起こす可能性があります。
レプリケーター
(Debian Buster - Linux 5.4.0-0.bpo.4-amd64)
1) ネットワーク名前空間を作成します。
$ unshare -n
$ echo $BASHPID
18807
2) veth を作成し、一端を上記で作成したネットワーク名前空間に移動します。
$ ip link add dev veth18807 type veth peer name eth18807
$ ip link set eth18807 netns 18807
$ ip addr | grep veth
14: veth18807@if13: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
3)tail -f /proc/18807/net/dev別の端末で実行
$ tail -f /proc/18807/net/dev
...
tail: /proc/18807/net/dev: file truncated
...leave hanging...
4）1）で名前空間を終了し、インターフェイスを一覧表示します。
$ ip addr | grep veth
14: veth18807@if13: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
以前に作成されたアイテムはvethまだ存在します。ただし、ステップ1）で作成されたネットワークネームスペースには明確な兆候はありません。lsns表示されず、/nsそのディレクトリにプロセスがありません。
中断すると、tail -fインターフェースはすぐに消えますip addr。尾である必要はなく、ただ開けておくだけでopen()十分です。
../net/dev開くにはネットワークネームスペースへの参照が必要になる可能性があるため、技術的にこれが意味があると思います。名前空間をこのようにアクティブに保つことは非常に驚くべきことです。
回避策としてveth使用する前に、作成したアセットを明示的に削除してくださいip link del。しかし、これがまだ名前空間を保存できるかどうか疑問に思います。
地獄の火の例
調査は、「すでに使用中」であるIPアドレスについて文句を言う防火犯メッセージによって引き起こされた。ウサギの穴に沿って下がると、最終的に固定IPを使用しているように見えます。次のように実行できます。
1) 刑務所を始める
$ /usr/local/bin/firejail --net=docker0 --ip=172.30.0.30 --noprofile
Parent pid 20890, child pid 20891
Interface MAC IP Mask Status
lo 127.0.0.1 255.0.0.0 UP
eth0 e2:87:2e:06:07:5b 172.30.0.30 255.255.0.0 UP
Default gateway 172.30.0.1
Child process initialized in 1491.22 ms
2）別の端末でnet/devサブキーを開きます。
$ tail -F /proc/20891/net/dev
3) 上記を終了しfirejail、同じパラメータで再起動します。
$ /usr/local/bin/firejail --net=docker0 --ip=172.30.0.30 --noprofile
Error: IP address 172.30.0.30 is already in use
上記のメッセージは、 veth がfirejailその IP の ARP 確認に応答し続けるからです。
ルーストアバウト
Dockerを使用して上記のFirejailシナリオを再現することはできません。コンテナが停止すると、インターフェイスは消えます。おそらくDockerが実際にip link del回避策（？）を実装した可能性があります。
引用する
Linuxコンテナとカーネルのバグに関する同様の観察が報告されました。
これは通常、コンテナのネットワーク名前空間が期限切れになっていないことを示し、通常カーネルに問題があることを示します。ネットワーク名前空間を使用する最後のプロセスが終了すると、名前空間が削除され、それによってすべての仮想インターフェイスが削除され、物理インターフェイスがホストネットワーク名前空間に戻ります。