LINUX.ORG.RU
Форум — General  

Проблемы systemd в гостевом CentOS 7 (из ubuntu 22)

 , ,


0

1

Дорогие форумчане, столкнулся с распространённой ошибкой в docker-контейнере с CentOS 7 (например, при выполнении systemctl status): «Failed to get D-Bus connection: No such file or directory»

При этом требования, перечисленные под заголовком «Dockerfile for systemd base image» на странице https://hub.docker.com/_/centos/ выполнены. И теперь не знаю, что делать. :/ Проблема в том, что CentOS 7 работает на ядре 3.10, а в хост-системе (Ubuntu) ядро 5.15. Таким образом, ядро в гостевой системе тоже 5.15 (что понятно). Подозреваю, что ошибка связана как-то с этим. Потому что при сборке и запуске этого же контейнера в хост-системе на CentOS 7 данной проблемы нет.

Куда теперь копать, ума не приложу.

← как сделать соответствие: первый элемент первого списка - первый элемент второго списка в циклах bash?
Как вывести информацию об установленном патче \ патча в СУБД PostgreSQL ? →

dbus в контейнере вообще есть?

Rootlexx ★★★★★
()

Проблема в том, что CentOS 7 работает на ядре 3.10, а в хост-системе (Ubuntu) ядро 5.15. Таким образом, ядро в гостевой системе тоже 5.15 (что понятно). Подозреваю, что ошибка связана как-то с этим.

Нет! D-Bus никакого отношения к ядру не имеет. Ваше сообщение об ошибке означает отсутствие запущенного dbus-daemon и соответственно - нет файла-сокета для связи с демоном.

sigurd ★★★★★
()
Последнее исправление: sigurd (всего исправлений: 1)

Дорогие форумчане, столкнулся с распространённой ошибкой в docker-контейнере с CentOS 7 (например, при выполнении systemctl status): «Failed to get D-Bus connection: No such file or directory»

Конечно, с распространённой. «В docker-контейнере» никакие systemctl status работать не будут по определению, т. к. внутри Docker-контейнера нет ни D-Bus, ни процесса init (в частности, systemd), ничего вообще. И не должно быть. Внутри Docker-контейнера должен жить ровно один процесс твоего приложения (ну, со своими потомками, если они есть).

Куда теперь копать, ума не приложу.

Если ты пытаешься использовать systemctl внутри Docker-контейнера, то ты делаешь всё не так и единственный возможный совет в такой ситуации — копать в сторону того, чтобы перестать так делать.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)

Вроде работает на Ubuntu 22.04. Нужны ключи --privileged и --cgroupns=host, без них systemd внутри контейнера не может смонтировать cgroup v1 контроллеры:

$ docker run --rm --privileged --cgroupns=host --name c7 -ti local/c7-httpd
systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization docker.
Detected architecture x86-64.

Welcome to CentOS Linux 7 (Core)!

Set hostname to <de5a4be19290>.
Initializing machine ID from random generator.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Local File Systems.
[  OK  ] Reached target Swap.
[  OK  ] Created slice Root Slice.
[  OK  ] Listening on Journal Socket.
[  OK  ] Listening on Delayed Shutdown Socket.
[  OK  ] Created slice System Slice.
         Starting Create Volatile Files and Directories...
[  OK  ] Reached target Slices.
         Starting Journal Service...
[  OK  ] Started Create Volatile Files and Directories.
[ INFO ] Update UTMP about System Boot/Shutdown is not active.
[DEPEND] Dependency failed for Update UTMP about System Runlevel Changes.
Job systemd-update-utmp-runlevel.service/start failed with result 'dependency'.
[  OK  ] Started Journal Service.
[  OK  ] Reached target System Initialization.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Reached target Sockets.
[  OK  ] Started Daily Cleanup of Temporary Directories.
[  OK  ] Reached target Timers.
[  OK  ] Reached target Basic System.
         Starting The Apache HTTP Server...
         Starting Cleanup of Temporary Directories...
[  OK  ] Started Cleanup of Temporary Directories.
[  OK  ] Started The Apache HTTP Server.
[  OK  ] Reached target Multi-User System.

Можно посмотреть статус:

$ docker exec c7 /bin/systemctl status
● de5a4be19290
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Fri 2022-12-02 20:08:45 UTC; 1min 30s ago
   CGroup: /
           ├─ 1 /usr/sbin/init
           ├─44 /bin/systemctl status
           └─system.slice
             ├─systemd-journald.service
             │ └─18 /usr/lib/systemd/systemd-journald
             └─httpd.service
               ├─19 /usr/sbin/httpd -DFOREGROUND
               ├─21 /usr/sbin/httpd -DFOREGROUND
               ├─22 /usr/sbin/httpd -DFOREGROUND
               ├─23 /usr/sbin/httpd -DFOREGROUND
               ├─24 /usr/sbin/httpd -DFOREGROUND
               └─25 /usr/sbin/httpd -DFOREGROUND
$

Можно остановить:

$ docker exec c7 /bin/systemctl poweroff
$

Контейнер останавливается:

[  OK  ] Stopped target Multi-User System.
[  OK  ] Stopped target Timers.
[  OK  ] Stopped Daily Cleanup of Temporary Directories.
         Stopping The Apache HTTP Server...
[  OK  ] Stopped The Apache HTTP Server.
[  OK  ] Stopped target Basic System.
[  OK  ] Stopped target Sockets.
[  OK  ] Closed D-Bus System Message Bus Socket.
[  OK  ] Stopped target System Initialization.
[  OK  ] Stopped Create Volatile Files and Directories.
[  OK  ] Reached target Shutdown.
Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
Powering off.
$
iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Так действительно работает! Но смущает ключ «–cgroupns=host». В этом случае процессы контейнера, выходит, не изолированы от хоста? И хост от контейнера, или я чего-то не понимаю?

Novascriptum
() автор топика
Ответ на: комментарий от iliyap

Сам ещё вот что нарыл:

mkdir -p /mnt/run/systemd/system /mnt/run/dbus
docker run -dit --name="test" \
--restart always --privileged --net test--ip 10.10.0.5 \
-p 61015:22 \
--hostname="test" \
--mount type=bind,source=/sys/fs/cgroup,destination=/sys/fs/cgroup,readonly  \
--mount type=bind,source=/mnt/run,destination=/run \
--mount type=bind,source=/run/dbus/system_bus_socket,destination=/run/dbus/system_bus_socket \
local/centos-7.9:systemd_ssh

В таком варианте тоже работает. Но если внутри контейнера сделать, например, reboot - то ребутится и хост-система. :/ И если установить в контейнере какую-то службу (хоть тот же nginx) и попытаться запустить:

systemctl start nginx

…он её не видит. По всей видимости, потому что в хосте её нет.

А если же в контейнер /run/dbus/system_bus_socket не пробрасывать и выполнить:

dbus-daemon --config-file=/usr/share/dbus-1/system.conf --print-address;

…то получаем:

[root@test /]# systemctl status
Failed to read server status: Input/output error

Дальше пробую:

strace systemctl status

…вывод большой, поэтому его запаковал в отдельный txt-файл.

Novascriptum
() автор топика
Ответ на: комментарий от Novascriptum

Можно запускать с --cgroupns=private. Это вызовет у тебя меньше сомнений и подозрений?

Монтировать /sys/fs/cgroup хоста в контейнер это плохая идея, нарушение изоляции.

Запускать dbus-daemon в контейнере тоже плохая идея. systemd сам реализует dbus в объёме, достаточном для systemctl.

Если так уж хочется dbus-daemon, можно запустить оригинальный centos:7 контейнер, без «обезжиривания» с помощью Dockerfile local/c7-systemd. В оригинале dbus-daemon запускается автоматом по зависимостям:

$ docker run --rm --privileged --cgroupns=host --env container=docker --tmpfs /sys/fs/cgroup --name c7 centos:7 /sbin/init
$ docker exec -ti c7 /bin/systemctl status
● bebfc6f90d36
    State: degraded
     Jobs: 0 queued
   Failed: 1 units
    Since: Fri 2022-12-02 21:02:53 UTC; 39s ago
   CGroup: /
           ├─ 1 /sbin/init
           ├─78 /bin/systemctl status
           ├─83 more
           └─system.slice
             ├─systemd-udevd.service
             │ └─30 /usr/lib/systemd/systemd-udevd
             ├─systemd-journald.service
             │ └─18 /usr/lib/systemd/systemd-journald
             ├─console-getty.service
             │ └─67 /sbin/agetty --noclear --keep-baud console 115200,38400,9600 li
nux
             ├─dbus.service
             │ └─54 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nop
idfile --systemd-activation
             └─systemd-logind.service
               └─56 /usr/lib/systemd/systemd-logind

Но зачем тебе dbus-daemon и зачем ты пытаешься просунуть сокет системной dbus-шины с хоста в контейнер я понять не могу. На хосте своя системная шина, в контейнере своя. Сервисы и на хосте и в контейнере имеют одинаковые названия, они не смогут жить на одной шине.

iliyap ★★★★★
()

Если по какой-то причине нужен docker-контейнер с systemd внутри, то пора докер менять на podman.

anonymous-angler ★☆
()

стандартная проблема, в центосе слишком старый systemd. Есть бэкпорт из федоры системд, его надо накатить и все будет хорошо.

Если точнее, systemd в centos7 не совместим c cgroupv2.

Надо поставить https://copr.fedorainfracloud.org/coprs/jsynacek/systemd-backports-for-centos-7/repo/epel-7/jsynacek-systemd-backports-for-centos-7-epel-7.repo

и сделать yum update.

AVL2 ★★★★★
()
Последнее исправление: AVL2 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← как сделать соответствие: первый элемент первого списка - первый элемент второго списка в циклах bash?
General
Как вывести информацию об установленном патче \ патча в СУБД PostgreSQL ? →