Início / server / Perguntas / 824975
Accepted
Snowcrash
Asked: 2017-01-09 12:35:56 +0800 CST

falha ao obter conexão D-Bus: Operação não permitida

  • 772

Estou tentando listar serviços na minha imagem do CentOS em execução no Docker usando

systemctl list-units

mas recebo esta mensagem de erro:

Failed to get D-Bus connection: Operation not permitted

Alguma sugestão de qual pode ser o problema?

centos docker systemd systemctl

4 respostas

  1. Best Answer

    Meu palpite é que você está executando um non-privilegedcontêiner. O systemd requer o recurso CAP_SYS_ADMIN, mas o Docker descarta esse recurso nos contêineres não privilegiados, para adicionar mais segurança.

    systemd também requer acesso RO ao sistema de arquivos cgroup dentro de um container. Você pode adicioná-lo com–v /sys/fs/cgroup:/sys/fs/cgroup:ro

    Então, aqui estão algumas etapas sobre como executar o CentOS com o systemd dentro de um contêiner do Docker:

    1. Extrair imagem do centos
    2. Configure um arquivo docker como o abaixo:
    FROM centos
MAINTAINER "Yourname" <[email protected]>
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. Construa -docker build -t centos7-systemd - < mydockerfile

    2. Execute um contêiner comdocker run --rm --privileged -ti -e container=docker -v /sys/fs/cgroup:/sys/fs/cgroup centos7-systemd /usr/sbin/init

    3. Você deve ter systemd em seu contêiner

    • 49

  2. Esta não é uma resposta direta à sua pergunta, mas pode realmente ser mais importante, e me deparei com essa percepção enquanto lia as outras respostas aqui.

    Eu tive alguma experiência em migrar alguns sistemas complicados para o Docker, e uma das percepções significativas que tive é que você deve idealmente ter um contêiner do Docker por aplicativo/serviço ou "por daemon".

    Uma razão muito significativa para isso é que o Docker não encerrará de forma limpa os serviços que você inicia com systemctl e, na verdade, você pode acabar com o mesmo tipo de corrupção de banco de dados que vem de uma queda de energia inesperada.

    Para mergulhar um pouco mais nisso: quando o Docker emite um comando "stop" para um contêiner, ele envia o sinal SIGTERM apenas para um único processo que foi iniciado com o CMD/ENTRYPOINT, não para todos os serviços e daemons. Para que um serviço tenha o aviso para ser encerrado de forma limpa e todos os outros sejam encerrados sem cerimônia.

    Se você absolutamente precisa empacotar dois serviços no mesmo container (ou seja, seu aplicativo e um banco de dados PostgreSQL ou algo parecido), então você precisa que seu CMD/ENTRYPOINT seja um script que capture SIGTERM e então o retransmita para esses serviços conhecidos. Isso pode ser feito, mas se você tiver a oportunidade, repense sua solução e tente dividi-la em vários contêineres.

    Um adendo

    Há uma nota/página interessante no site do Docker sobre o uso do supervisord se você realmente precisar ter vários serviços em execução no mesmo contêiner.

    • 14

  3. Consegui corrigir esse problema em um contêiner CentOS:7 Docker. Eu segui principalmente o Guide on CentOS Docker image project .

    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"]

    Agora, construa a imagem e execute-a usando pelo menos os seguintes argumentos para docker runcommand:-v /run -v /sys/fs/cgroup:/sys/fs/cgroup:ro

    Então o ponto principal é que /usr/sbin/initdeve ser o primeiro processo dentro do container Docker.

    Portanto, se você quiser usar um script personalizado que execute alguns comandos antes de executar /usr/sbin/init, inicie-o no final do script usando exec /usr/sbin/init(em um script bash).

    Aqui está um exemplo:

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

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

    E aqui está o conteúdo de 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

    Você poderia ter System is booting up. See pam_nologin(8)se estiver usando o sistema PAM, nesse caso, delete /usr/lib/tmpfiles.d/systemd-nologin.confno seu Dockerfileporque ele cria o arquivo /var/run/nologinque gera esse erro específico.

    • 9

  4. Eu não queria ter que iniciar o systemd como init/PID 1. Depois de executar as etapas de limpeza mencionadas por outras pessoas, iniciei o systemd de dentro de um script de inicialização como /usr/lib/systemd/systemd --system &.

    Isso permitiu que o systemd iniciasse e iniciasse os serviços registrados, mas o systemctl estava falhando com o erro D-Bus.

    Para mim, o elo perdido era a ausência do /run/systemd/systemdiretório, descobri isso straceing systemctl.

    Criar este diretório manualmente antes de executar o systemctl permite que o systemctl funcione para mim.

    • 2

relate perguntas