習LXC遇諸

爲了解決某些問題（後來發現不可），這兩天看了看coolshell中LXC的“教程”[1][2]，在運行“示例”之時發現有些執行結果和原文中所說並不一樣，遂上網查之，有得解，有未得解。

（本文作於9.26日）

一、hostname不變

在運行第一個示例時便出現問題。我起初在一臺舊筆記本上（archlinux，一個多月未更新）折騰，發現容器中的sethostname()未起作用，hostname沒有改變。一開始以爲是內核的問題，於是更新內核到源中的最新版（4.16），但仍舊無果。

然而昨天換到另一臺電腦上（archlinux，更到最新）時，該問題從未出現……猜測是某個庫（glibc？）有bug。

二、另一掛載命名空間中的子進程會影響外部文件系統

該問題在玩mount namespace時候偶然發現。程序在clone時加入了CLONE_NEWNS，子進程中有句system(mount -t proc proc /proc)，乍看之下一切正常。然而在這句話執行過後，外部文件系統中的/proc也變成了新掛載的！

最初以爲是命名空間未生效，但是/proc/PID/ns/下的內容顯示確實從屬於另一個命名空間。然後腦子裏的第一個反應是：內核bug。但是想想應該不會，畢竟這個命名空間實現得很早，有bug應該早就發現並解決了。

再後來翻了翻查了查，在一個博客（人家說原文是這個，奇妙的是coolshell最初幾個示例和這裏的幾乎一樣，而據coolshell博主說他從未看過這篇博文）的評論中發現了一條鏈接，徹底解決了我的疑問。

Linux的掛載功能已經過擴展，不再是原先UNIX的全局一棵樹。

子進程在執行時候複製父進程的目錄結構，然後自己可以進行變化（當爲另一命名空間）。然而這樣可能導致新加入的設備掛載點（例如光盤）不出現在子進程中，於是掛載點有了幾種屬性：shared、slave、private、unbindable以及相應的遞歸版。

shared保證掛載點變化時，其他命名空間中的相同掛載點也變化；

slave保證（其他命名空間中的）掛載點變化時，該掛載點也會跟隨變化；

private保證掛載點不會隨其他命名空間中的變化；

unbindable在private的基礎上進一步保證不可bind掛載。

我看了一眼我的/proc/self/mountinfo，看到/proc（其實是所有）是shared屬性，問題豁然明朗。解決方案很簡單，將/proc換爲private：

# mount --make-private /proc

• 相关文章