systemctl n'a pas réussi à se connecter au bus - docker ubuntu: 16.04 container

43

J'essaie d'utiliser la commande systemctl dans un conteneur ubuntu:16.04 docker. Je cours la commande suivante ...

systemctl status ssh

Cependant, j'obtiens l'erreur ...

Failed to connect to bus: No such file or directory

Pourquoi cela ne fonctionne pas? Est-ce lié à Ubuntu exécuté dans un conteneur Docker? Comment puis-je obtenir que systemctl fonctionne correctement?

    
posée Duncan Gravill 18.08.2016 - 01:19
la source

7 réponses

16

Je suppose que vous démarrez votre conteneur Docker avec quelque chose comme

docker run -t -i ubuntu:16.04 /bin/bash

Le problème est maintenant que votre processus d'initialisation PID 1 est /bin/bash , pas systemd. Confirmez avec ps aux .

En plus de ce que vous manquez de dbus serait le moyen de communiquer. C'est de là que vient votre message d'erreur. Mais comme votre PID 1 n’est pas systemd, il ne sera pas utile d’installer dbus.

Le mieux serait de repenser la façon dont vous prévoyez d’utiliser docker. Ne vous fiez pas à systemd en tant que gestionnaire de processus, mais que le conteneur docker exécute l'application souhaitée au premier plan.

    
réponse donnée user228505 02.09.2017 - 09:04
la source
7

D'autres ont signalé un problème similaire. Démarrez le terminal et tapez:

$ env

Voyez-vous une variable d’environnement comme celle-ci?

XDG_RUNTIME_DIR=/run/user/'id -u'

id -u est placé entre guillemets et non entre guillemets. Cette variable est réinterprétée en un nombre généralement 1000 pour les utilisateurs réguliers et 0 pour les super-utilisateurs (sudo).

Si la variable d'environnement XDG_RUNTIME_DIR n'existe pas, vous devez la créer. La discussion complète se trouve dans les réponses de launchpad systemd .

    
réponse donnée WinEunuuchs2Unix 18.08.2016 - 05:57
la source
1

Vous n’utilisez peut-être pas systemd , qui est l’implémentation par défaut de init le 16.04. Si vous avez effectué une mise à niveau à partir de 14.04, vous exécutez probablement upstart , et le résultat de l'exécution de la commande systemctl est le résultat obtenu.

Voir ma réponse à systemctl: comand introuvable 16.04 server pour plus.

    
réponse donnée Hugh Buntu 30.05.2017 - 05:54
la source
1

Essayez ceci:

docker run -ti -d --privileged=true images_docker  "/sbin/init"

ou

docker run -ti -d --privileged=true images_docker

sera le même résultat.

Je reçois ici de la doc de Docker :

  

Par défaut, les conteneurs Docker sont "sans privilèges" et ne peuvent pas, par exemple, exécuter un démon Docker dans un conteneur Docker. En effet, par défaut, un conteneur n'est autorisé à accéder à aucun périphérique, mais un conteneur "privilégié" a accès à tous les périphériques (voir la documentation sur les périphériques cgroups).

     

Lorsque l'opérateur exécute docker run --privileged, Docker activera l'accès à tous les périphériques de l'hôte et définira une configuration dans AppArmor ou SELinux pour autoriser le conteneur pratiquement tous le même accès à l'hôte que les processus exécutés en dehors des conteneurs. sur l'hôte. Des informations supplémentaires sur l'utilisation de --privileged sont disponibles sur le blog Docker.

    
réponse donnée sonjaya sonjaya 09.05.2018 - 09:42
la source
0

Dans le conteneur Docker, je pense que vous pouvez mettre à jour-rc.d si vous avez encore du mal avec systemd. J'ai essayé avec update-rd.c et ça marche.

    
réponse donnée NEERAJ SWARNKAR 08.01.2018 - 13:06
la source
0

Si vous obtenez cette erreur dans le sous-système Windows pour Linux (WSL), je l'ai trouvée car Docker n'est pas pris en charge. Cela est dû au manque de groupes de contrôle et d’autres conditions préalables.

    
réponse donnée ijustlovemath 23.06.2018 - 18:00
la source
-1

J'obtiens exactement la même erreur et je l'exécute avec sudo

sudo systemctl status ssh
    
réponse donnée Saif 19.01.2018 - 17:29
la source

Lire d'autres questions sur les étiquettes