☰

LXC の起動/停止がハングし、ファイルシステムの同期がハングする

tag-icon • tag-icon linux debian kernel lxc
LXC の起動/停止がハングし、ファイルシステムの同期がハングする

編集: 問題は、umask がデフォルトの 022 ではなく 027 に設定されていたことです。詳細については以下を参照してください。

LXC に関して、発生するとシステム全体に現れる一連の不可解な問題を経験しています。

LXC コンテナを起動/停止するときに、起動または停止が無期限にハングすることがあります。起動時にこれが発生すると、コンテナのinitプロセスは実行中ですが、 を使用しても強制終了できませんkill -9。コンテナはオンラインになることはなく、プロセスを終了する唯一の方法はシステムを再起動することです。

問題は、システムが再起動しなくなることです。この問題と同時に、 の実行中にupdate-initramfs、無期限にハングする問題にも気づきました。次のことがわかった後: https://unix.stackexchange.com/questions/428001/update-initramfs-hangs-on-debian-stretchsync私は、コマンド（ユーティリティとシステムコールの両方）がハングアップし、LXCが動作せず、update-initramfsハングアップし、システムのシャットダウンがハングアップする（ファイルシステムをアンマウントする前に行うべきこと） という結論に達しましたsync。この問題が発生すると、syncコマンドラインから（ユーティリティを）呼び出すと、常に無期限にハングアップします。実行してみましたstraceが、カーネルコールに入るとトレースが終了し、それ以上デバッグできません。私は、次の方法でキャッシュを監視しました。これしかし、それは 100kB 未満の範囲で推移します。

ファイルシステムに関係することを考えると、syncLXC が何らかのファイルシステムを処理する方法に問題があると予想されます。LXC を使用していない別の同一のサーバーがあり、の出力を比較した後、mountそのサーバーに存在しないファイルシステムをアンマウントしましたが、効果はありませんsyncでした。ハングし続けます。

さて、クリーンブートでLXCに触れずに、sync いつも動作し、動作し続けます。この理由と、他の問題が見られないという事実から、実際の I/O の問題はないと確信しています。また、コンテナーが正常に起動した場合、問題は発生しないようです。

私はこの問題についてインターネットを隅々まで調べましたが、何も見つかりません。

カーネル 4.19.0-0.bpo.4-amd64 を搭載した Debian 9 (安定版) 上の LXC 2.0.7-2+deb9u2 (最近の他のカーネルでも発生しましたが)、 用に 2 つの SSD を RAID1 で/、 用に 3 つの HDD を RAID5 (mdadm) で構成/home。ゲストは Debian 9 (stretch) または 10 (buster) で、非特権コンテナーとして実行されています。問題は次のように絞り込まれたようです: 特権コンテナでは問題は発生しませんでした。

ゲストコンテナの設定例:

# Template used to create this container: /usr/share/lxc/templates/lxc-download

# Distribution configuration
lxc.include = /usr/share/lxc/config/debian.common.conf
lxc.include = /usr/share/lxc/config/debian.userns.conf
lxc.arch = linux64

# Container specific configuration
lxc.id_map = u 0 200000 100000
lxc.id_map = g 0 200000 100000

# Network configuration
#lxc.network.type = empty
lxc.network.type = veth
lxc.network.link = lxcbr0
lxc.network.flags = up
lxc.network.hwaddr = 00:16:3e:e9:4a:e7
lxc.rootfs = /var/lib/lxc/somename/rootfs
lxc.rootfs.backend = dir
lxc.utsname = somename

# Mounts
lxc.mount.entry = /var/lib/lxc/temp mnt/temp none bind 0 0

および subuid/gid マッピング:

# cat /etc/s*id
root:100000:1000000000
root:100000:1000000000

コンテナの作成、起動、および停止の失敗の例:

# lxc-create -n test -t download
...
Distribution: debian
Release: stretch
Architecture: amd64

Downloading the image index
Downloading the rootfs
Downloading the metadata
The image cache is now ready
Unpacking the rootfs

---
You just created a Debian stretch amd64 (20190522_05:24) container.

# lxc-ls -f
NAME          STATE   AUTOSTART GROUPS IPV4 IPV6 
test          STOPPED 0         -      -    -    

# lxc-start -n test

# lxc-ls -f
NAME          STATE   AUTOSTART GROUPS IPV4 IPV6 
test          RUNNING 0         -      -    -    

# lxc-attach -n test
root@test:/# ls -alh /
total 68K
drwxr-xr-x  21 root   root    4.0K May 22 05:26 .
drwxr-xr-x  21 root   root    4.0K May 22 05:26 ..
drwxr-xr-x   2 root   root    4.0K May 22 05:26 bin
drwxr-xr-x   2 root   root    4.0K Mar 28 09:12 boot
drwxr-xr-x   4 root   root     400 May 22 09:26 dev
drwxr-xr-x  42 root   root    4.0K May 22 09:24 etc
drwxr-xr-x   2 root   root    4.0K Mar 28 09:12 home
drwxr-xr-x   9 root   root    4.0K May 22 05:25 lib
drwxr-xr-x   2 root   root    4.0K May 22 05:25 lib64
drwxr-xr-x   2 root   root    4.0K May 22 05:25 media
drwxr-xr-x   2 root   root    4.0K May 22 05:25 mnt
drwxr-xr-x   2 root   root    4.0K May 22 05:25 opt
dr-xr-xr-x 225 nobody nogroup    0 May 22 09:26 proc
drwx------   2 root   root    4.0K May 22 05:25 root
drwxr-xr-x   3 root   root      60 May 22 09:26 run
drwxr-xr-x   2 root   root    4.0K May 22 05:26 sbin
drwxr-xr-x   2 root   root    4.0K May 22 05:25 srv
dr-xr-xr-x  13 nobody nogroup    0 May 19 17:07 sys
drwxrwxrwt   2 root   root    4.0K May 22 05:25 tmp
drwxr-xr-x  10 root   root    4.0K May 22 05:25 usr
drwxr-xr-x  11 root   root    4.0K May 22 05:25 var
root@test:/# exit

# lxc-ls -f
NAME          STATE   AUTOSTART GROUPS IPV4 IPV6 
debian_buster STOPPED 0         -      -    -    
rtorrent      STOPPED 0         -      -    -    
test          RUNNING 0         -      -    -    

# lxc-stop -n test
^C

# lxc-stop -n test
... continues to hang ...
# ^C
# sync
^C^C^Z^X^C^Z^X^C^Z^C^Z^X^C
... won't die.

答え1

結局のところ、問題はデフォルトよりも制限の少ない umask でした。Debian のデフォルトは 022 ですが、.bashrcセキュリティ上の理由から、ユーザー アカウントで 027 に変更しました。 を使用してsuroot になると、この umask がコピーされ、すべてのlxc-*コマンドが umask 027 で実行されます。ただし、これにより LXC の既知の問題が発生し、何らかの理由でまだ修正されていません (少なくとも Debian パッケージでは?)。

umask を変更すると (セッション内または を変更することによって.bashrc)、既存のコンテナーを問題なく実行できるようになります。

リソース：

https://discuss.linuxcontainers.org/t/cannot-stop-unprivileged-container-not-even-kill-9-its-systemd-process-on-host/1079

参考:(同じ問題かどうかはわかりません)

参考:

参考:

関連情報