Назад | Перейти на главную страницу

не удалось установить соединение D-Bus: операция не разрешена

Я пытаюсь перечислить службы в моем образе CentOS, запущенном в Docker, используя

systemctl list-units

но я получаю это сообщение об ошибке:

Failed to get D-Bus connection: Operation not permitted

Есть предложения, в чем может быть проблема?

Я предполагаю, что у вас non-privileged контейнер. systemd требует возможности CAP_SYS_ADMIN, но Docker отбрасывает эту возможность в непривилегированных контейнерах, чтобы повысить безопасность.

systemd также требует доступа RO к файловой системе cgroup в контейнере. Вы можете добавить это с помощью –v /sys/fs/cgroup:/sys/fs/cgroup:ro

Итак, вот несколько шагов, как запустить CentOS с systemd внутри контейнера Docker:

  1. Вытяните изображение Centos
  2. Настройте файл докера, как показано ниже:
FROM centos
MAINTAINER "Yourname" <youremail@address.com>
ENV container docker
RUN yum -y update; yum clean all
RUN yum -y install systemd; yum clean all; \
(cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == systemd-tmpfiles-setup.service ] || rm -f $i; done); \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;
VOLUME [ "/sys/fs/cgroup" ]
CMD ["/usr/sbin/init"]
  1. Построить это - docker build --rm -t centos7-systemd - < mydockerfile

  2. Запустите контейнер с docker run --privileged -ti -e container=docker -v /sys/fs/cgroup:/sys/fs/cgroup centos7-systemd /usr/sbin/init

  3. У вас должен быть systemd в вашем контейнере

Это не прямой ответ на ваш вопрос, но на самом деле он может быть более важным, и я столкнулся с этим осознанием, когда читал другие ответы здесь.

У меня был некоторый опыт миграции некоторых сложных систем на Docker, и я понял, что в идеале у вас должен быть один контейнер Docker для каждого приложения / службы или «для каждого демона».

Одна очень важная причина этого заключается в том, что Docker не будет полностью отключать службы, которые вы запускаете с помощью systemctl и на самом деле вы можете столкнуться с такими же повреждениями базы данных, которые возникают в результате неожиданного отключения электроэнергии.

Чтобы погрузиться в это немного глубже: когда Docker выдает команду «остановить» контейнеру, он отправляет сигнал SIGTERM только одному единственному процессу, который был запущен с помощью CMD / ENTRYPOINT, а не всем службам и демонам. Таким образом, одна служба имеет предупреждение о полном завершении работы, а все остальные бесцеремонно завершаются.

Если вам абсолютно необходимо упаковать две службы в один и тот же контейнер (то есть ваше приложение и базу данных PostgreSQL или что-то в этом роде), вам нужно, чтобы ваш CMD / ENTRYPOINT был сценарием, который улавливает SIGTERM, а затем ретранслирует его в эти известные службы. Это можно сделать, но если у вас есть возможность, переосмыслите свое решение и попробуйте разбить его на несколько контейнеров.

Приложение

Есть интересный примечание / страница на сайте Docker об использовании supervisord, если вам абсолютно необходимо, чтобы несколько служб работали в одном контейнере.

Мне удалось исправить эту проблему в контейнере CentOS: 7 Docker. Я следил в основном Руководство по проекту образа CentOS Docker.

FROM centos:7

ENV container docker
RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == \
systemd-tmpfiles-setup.service ] || rm -f $i; done); \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;

# Install anything. The service you want to start must be a SystemD service.

CMD ["/usr/sbin/init"]

Теперь создайте образ и запустите его, используя по крайней мере следующие аргументы для docker run команда: -v /run -v /sys/fs/cgroup:/sys/fs/cgroup:ro

Тогда главное то, что /usr/sbin/init должен быть первым процессом внутри контейнера Docker.

Итак, если вы хотите использовать собственный сценарий, который выполняет некоторые команды перед запуском /usr/sbin/init, запустите его в конце вашего скрипта, используя exec /usr/sbin/init (в сценарии bash).

Вот пример:

ADD cmd.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/cmd.sh

CMD ["/usr/local/bin/cmd.sh"]

А вот содержание cmd.sh:

#!/bin/bash

# Do some stuffs

exec /usr/sbin/init # To correctly start D-Bus thanks to https://forums.docker.com/t/any-simple-and-safe-way-to-start-services-on-centos7-systemd/5695/8

Ты мог бы иметь System is booting up. See pam_nologin(8) если вы используете систему PAM, в этом случае удалите /usr/lib/tmpfiles.d/systemd-nologin.conf в твоем Dockerfile потому что он создает файл /var/run/nologin который генерирует эту конкретную ошибку.

Я не хотел запускать systemd как init / PID 1. После выполнения шагов очистки, упомянутых другими, я запускаю systemd из сценария запуска как /usr/lib/systemd/systemd --system &.

Это позволяло systemd запускать и запускать зарегистрированные службы, но systemctl выдает ошибку D-Bus.

Для меня отсутствующим звеном было отсутствие каталога / run / systemd / system, обнаруженного straceing systemctl.

Создание этого каталога вручную перед запуском systemctl позволяет systemctl работать на меня.