Answers:
我假设您使用类似以下内容启动docker容器
docker run -t -i ubuntu:16.04 /bin/bash
现在的问题是您的初始化进程PID 1是/bin/bash
,而不是systemd。用确认ps aux
。
除此之外,您还缺少dbus与之沟通。这是您的错误消息的来源。但是由于您的PID 1没有systemd,因此无助于安装dbus。
最好是重新考虑您打算使用docker的方式。不要依赖systemd作为进程管理器,而是让docker容器在前台运行所需的应用程序。
docker log
。
/sbin/init
正在被PID = 1进程接收到此错误。--privileged=true
根据@sonjaya sonjaya的建议添加以下内容即可解决此问题。
其他人也报告了类似的问题。启动终端并输入:
$ env
您看到这样的环境变量吗?
XDG_RUNTIME_DIR=/run/user/`id -u`
当id -u
用反引号不是单引号。通常1000
对于普通用户和0
超级用户(sudo),此变量都会重新解释为数字。
如果环境变量XDG_RUNTIME_DIR
不存在,则需要创建它。完整的讨论在launchpad systemd答案中。
root
,因此我使用了变量XDG_RUNTIME_DIR=/run/root/0
,但没有成功。然后我检查了文件夹/run
,发现没有子文件夹/run/root
。无论如何,我可以获得更详细的错误消息吗?我看了一下,systemctl --help
但是看不到获取详细错误消息的方法。
PID 1
通常如何systemd
在Docker容器中用容器Entrypoint替换后者。
尝试这个:
docker run -ti -d --privileged=true images_docker "/sbin/init"
要么
docker run -ti -d --privileged=true images_docker
将是相同的结果。
默认情况下,Docker容器是“无特权的”,并且例如不能在Docker容器内运行Docker守护程序。这是因为默认情况下,不允许容器访问任何设备,但是授予“特权”容器访问所有设备的权限(请参阅cgroups设备上的文档)。
当操作员执行docker run --privileged操作时,Docker将启用对主机上所有设备的访问,并在AppArmor或SELinux中进行一些配置,以允许容器对主机的访问几乎与在主机上容器外部运行的进程相同。有关使用--privileged运行的更多信息,请参阅Docker Blog。
您可能没有运行systemd,这是16.04 上init的默认实现。如果从14.04升级,则很可能仍在运行upstart,并且运行systemctl命令的结果是得到的输出。
请参阅我在systemctl上的回答:comand not found 16.04 server for more。
在docker容器中,如果您仍在为systemd苦苦挣扎,我认为您可以update-rc.d。我尝试使用update-rd.c并成功。
我遇到了完全相同的错误,然后使用 sudo
sudo systemctl status ssh
sudo
。似乎是巧合。你能重新测试吗?
saif@sr-server:~$ systemctl status ssh
Failed to connect to bus: No such file or directory
saif@sr-server:~$ sudo systemctl status ssh
[sudo] password for saif:
● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-01-19 23:38:14 PKT; 4min 4s ago Main PID: 18222 (sshd) Tasks: 15 Memory: 32.7M CPU: 488ms
service ssh start