lxcfs下載lxcfs源代碼下載

lxcfs

C#源碼

LXC

下載

LXCFS

介紹

LXCFS是一個編寫的小型保險絲文件系統，目的是使Linux容器更像虛擬機。它是從LXC的側面項目開始的，但可在任何運行時使用。

LXCF將注意procfs中關鍵文件提供的信息，例如：

 /proc/cpuinfo
/proc/diskstats
/proc/meminfo
/proc/stat
/proc/swaps
/proc/uptime
/proc/slabinfo
/sys/devices/system/cpu/online

集裝箱知道顯示的值（例如/proc/uptime ）確實反映了容器正在運行多長時間，而不是主機運行的時間。

在實現Serge Hallyn LXCFS的Cgroup名稱空間之前，還提供了一個容器Aware cgroupfs樹。注意該容器只能訪問其自己的CGroups下方的CGroups，因此提供了額外的安全性。對於不支持Cgroup名稱空間的系統， LXCFS仍將提供此功能，但大多被認為是棄用的。

升級`LXCFS`而無需重新啟動

LXCFS分為共享庫（確切地說是Libtool模塊） liblxcfs和一個簡單的二進制lxcfs 。升級到較新版本的LXCFS時， lxcfs二進制將不會重新啟動。相反，它將檢測到共享庫的新版本可用，並將使用dlclose(3)和dlopen(3)重新加載它。選擇了此設計，以便不需要重新啟動LXCFS使用的保險絲主循環。如果是使用LXCFS的所有容器，則需要重新啟動，因為否則它們將留下保險絲折疊式安裝座。

要在下一個可能的實例中強制共享庫的重新加載，只需將SIGUSR1發送到運行LXCFS進程的PID即可。這可以和這樣做一樣簡單：

 rm /usr/lib64/lxcfs/liblxcfs.so # MUST to delete the old library file first
cp liblxcfs.so /usr/lib64/lxcfs/liblxcfs.so # to place new library file
kill -s USR1 $(pidof lxcfs) # reload

musl

為了通過共享庫重新加載實現平穩的升級， LXCFS也取決於以下事實：當dlclose(3)刪除最後一個對共享庫災難的引用時，運行了dlopen(3)時稱為構造函數。雖然對於glibc來說是正確的，但對於musl而言，這是不正確的（請參閱“卸載庫”。）。因此，建議musl上的LXCFS用戶完全重新啟動LXCFS ，並使用所有容器。

建築

為了構建LXCFS，請根據您的發行版安裝保險絲和保險絲開發標頭。 LXCFS更喜歡fuse3但確實可以與新的fuse2版本一起使用：

 git clone git://github.com/lxc/lxcfs
cd lxcfs
meson setup -Dinit-script=systemd --prefix=/usr build/
meson compile -C build/
sudo meson install -C build/

要使用消毒器構建，您必須指定-Db_sanitize=...選項到meson setup 。例如，啟用Asan和Ubsan：

 meson setup -Dinit-script=systemd --prefix=/usr build/ -Db_sanitize=address,undefined
meson compile -C build/

用法

運行LXCFS的推薦命令是：

 sudo mkdir -p /var/lib/lxcfs
sudo lxcfs /var/lib/lxcfs

希望使用LXCFS容器運行時應將其固定在容器啟動的正確位置中。

LXC

為了將LXCF與基於系統的容器一起使用，您可以使用LXC 1.1在這種情況下可以自動工作，或者在其他情況下複製lxc.mount.hook和lxc.reboot.hook /usr/share/lxcfs

 lxc.mount.auto = cgroup:mixed
lxc.autodev = 1
lxc.kmsg = 0
lxc.include = /usr/share/lxc/config/common.conf.d/00-lxcfs.conf

與Docker一起使用

 docker run -it -m 256m --memory-swap 256m 
      -v /var/lib/lxcfs/proc/cpuinfo:/proc/cpuinfo:rw 
      -v /var/lib/lxcfs/proc/diskstats:/proc/diskstats:rw 
      -v /var/lib/lxcfs/proc/meminfo:/proc/meminfo:rw 
      -v /var/lib/lxcfs/proc/stat:/proc/stat:rw 
      -v /var/lib/lxcfs/proc/swaps:/proc/swaps:rw 
      -v /var/lib/lxcfs/proc/uptime:/proc/uptime:rw 
      -v /var/lib/lxcfs/proc/slabinfo:/proc/slabinfo:rw 
      -v /var/lib/lxcfs/sys/devices/system/cpu:/sys/devices/system/cpu:rw 
      ubuntu:18.04 /bin/bash

在啟用交換的系統中，可以使用參數“ -u”來設置“ meminfo”中的所有值，該值指的是互換為0。

sudo lxcfs -u/var/lib/lxcfs

交換處理

如果您注意到LXCF在系統上交換時未在容器中顯示任何交換，請仔細閱讀本節，並查找有關如何啟用交換的說明。

在Linux上交換CGroup處理非常令人困惑，而LXCF的處理方式並不是一個完美的方法。

以下術語：

RAM memory.limit_in_bytes memory.usage_in_bytes
RAM+交換參考memory.memsw.usage_in_bytes and memory.memsw.limit_in_bytes

主要問題是：

交換會計通常是選擇加入的，需要特殊的內核啟動時間選項（ swapaccount=1 ）和/或特殊的內核構建選項（ CONFIG_MEMCG_SWAP ）。
可以設置RAM限制和RAM+交換限制。但是，三角洲並不是可用的交換空間，因為內核仍然可以自由交換最大的RAM。這使得不可能使用RAM和RAM+交換之間的三角洲進行交換設備尺寸，因為這不會說明內核交換更多頁面，從而導致交換使用率超過交換總額。
在給定的容器中禁用交換是不可能的。可以完成的最接近的是將交換設置為0，這嚴重限制了交換頁面的風險，但不會消除它。

結果，LXCF必須做出一些妥協，如下：

當未啟用交換會計時，根本沒有報告交換空間。這僅僅是因為沒有辦法知道掉期消耗。但是，容器可能會使用一些交換，但根本無法知道其中的多少並顯示交換設備需要報告某種交換用法。顯示主機值將是完全錯誤的，顯示0值是相等的錯誤。
由於給定容器的互換使用量可以超過RAM和RAM+交換之間的增量，因此據報導，交換大小始終是RAM+交換限制的較小或主機交換設備本身的較小。這樣可以確保絕對不允許使用交換量超過掉期大小。
如果將交換設置為0，並且沒有互換用法，則不會報告交換。但是，如果使用互換，則報告使用使用尺寸的交換設備（100％滿）。這提供了足夠的報告記憶消耗，同時防止應用程序假設有更多交換。

問題報告

核心轉儲

如果發生LXCFS崩潰，對於我們來說，擁有LXCFS過程內存的核心轉儲對於我們來說非常有用。

請檢查/var/crash和coredumpctl list以防萬一您已經有lxcfs核心轉儲文件
如果沒有，您可以使用以下方式從系統中收集它：

在運行LXCFS的機器上，執行為root：

 # save an old core_pattern setting value:
cat /proc/sys/kernel/core_pattern > /root/core_pattern.old_value.bak

# set a new one to collect all core dumps:
echo '|/bin/sh -c $@ -- eval exec gzip --fast > /var/crash/core-%e.%p.gz' > /proc/sys/kernel/core_pattern

# wait for the next LXCFS crash and check
ls -lah /var/crash

# there should be a file with a name like "core-lxcfs.80581.gz". Please, upload it somewhere and share with us.

# restore the old "core_pattern" value:
cat /root/core_pattern.old_value.bak > /proc/sys/kernel/core_pattern

展開

附加信息