правка: Проблема была в том, что мой umask был установлен на 027, а не на 022 по умолчанию. Подробности см. ниже.
Я столкнулся с рядом сбивающих с толку проблем, связанных с LXC, которые проявляются во всей системе после возникновения.
При запуске/остановке контейнеров LXC иногда запуск или остановка зависают на неопределенное время. Когда это происходит при запуске, процесс контейнера initзапущен, но не может быть остановлен, даже с помощью kill -9. Контейнер никогда не подключается к сети, и единственный способ завершить процесс — перезагрузка системы.
Дело в том, что система больше не перезагружается. В то же время, что и эта проблема, я заметил проблему при запуске update-initramfs, которая также зависает на неопределенное время. После того, как я нашел это:
https://unix.stackexchange.com/questions/428001/update-initramfs-hangs-on-debian-stretch
Я пришел к выводу, что syncкоманда (и утилита, и системный вызов) действительно зависают, из-за чего LXC не работает, update-initramfsзависает и зависает при завершении работы системы (как это syncдолжно быть сделано перед размонтированием файловых систем). После возникновения проблемы вызов sync(утилиты) из командной строки будет постоянно зависать на неопределенное время. Я пробовал запустить ее, straceно трассировка заканчивается при переходе к вызову ядра, и я не могу отлаживать дальше. Я отслеживал кэши с помощьюэтотно он просто колеблется в диапазоне <100 КБ.
Учитывая, что syncэто связано с файловыми системами, я предполагаю, что что-то не так с тем, как LXC обрабатывает некоторые файловые системы. У меня есть другой идентичный сервер, который не использует LXC, и после сравнения вывода mountя размонтировал файловые системы, отсутствующие на нем, но безрезультатно. syncпродолжает висеть.
Теперь, при чистой загрузке и не трогая LXC,sync всегдаработает и продолжает работать. По этой причине и по тому факту, что я не вижу других проблем, я уверен, что нет никаких реальных проблем ввода-вывода. Также, когда контейнер успешно запускается, у него, похоже, нет никаких проблем.
Я долго и упорно искал информацию в Интернете по этому вопросу, но безуспешно.
LXC 2.0.7-2+deb9u2 на Debian 9 (стабильный) с ядром 4.19.0-0.bpo.4-amd64 (хотя это случалось и в других последних ядрах), с 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 из соображений безопасности. При использовании suдля получения прав root этот umask копируется таким образом, что все lxc-*команды выполняются с umask 027. Однако это приводит к известной проблеме с LXC, которая по какой-то причине до сих пор не исправлена (по крайней мере, в пакетах Debian?).
Изменение umask (в сеансе или путем изменения .bashrc) позволяет мне без проблем запускать уже имеющиеся у меня контейнеры.
Ресурсы:
https://github.com/lxc/lxc/issues/2277(не уверен, что это та же проблема)