systemctl failed to connect to bus - docker ubuntu:16.04 container

Question

I'm trying to use the systemctl command in a ubuntu:16.04 docker container. I'm running the following command...

systemctl status ssh

However I'm getting the error...

Failed to connect to bus: No such file or directory

Why is this not working? Is this related to Ubuntu running in a docker container? How can I get systemctl to work correctly?

For those who have the same problem with sudo systemctl --user ... just remove the sudo ! — 56ka, Apr 18 '20 at 21:59
Holy shit. I had systemctl aliased to sudo systemctl --no-pager. Thanks for the tip. — Paul, Sep 22 '20 at 17:38

score 77 · Accepted Answer · edited Dec 11 '22 at 14:42

77

I assume you start your docker container with something like

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

The problem now is that your init process PID 1 is /bin/bash, not systemd. Confirm with ps aux.

In addition to that you are missing dbus, which would be the way to communicate. This is where your error message is coming from. But as your PID 1 is not systemd, it will not help to install dbus.

Best would be to re-think the way you plan to use docker. Do not rely on systemd as a process manager but have the docker container run your desired application in the foreground.

edited Dec 11 '22 at 14:42

tanius

6,303
1
39
49

answered Sep 02 '17 at 07:04

user228505

1,659
1
16
15

Services like openssh-server are configured to log to the default syslog facility. How can I get sshd logs without relying on systemctl? – Parth Shah Oct 04 '18 at 20:17
@ParthShah please check out sshd man page. Mine has the following options: By caling it with -D you can keep it in the foreground. with -e you instruct it to directly print the logs. these can then later be inspected the docker way with docker log. – user228505 Oct 08 '18 at 14:13
[FYI] was getting this error with /sbin/init being PID=1 process. Adding --privileged=true as suggested by @sonjaya sonjaya below solved the isssue. – DimG Jan 29 '19 at 15:36
beautiful answer!! – Sachin Verma Jul 22 '19 at 12:03

WinEunuuchs2Unix · Answer 2 · 2017-07-22T16:16:42.757

21

Others have reported a similar problem. Start up the terminal and type:

$ env

Do you see an environment variable like this?

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

Where id -u is enclosed in backticks not single quotes. This variable is reinterpreted into a number usually 1000 for regular users and 0 for super user (sudo).

If the environment variable XDG_RUNTIME_DIR does not exist you need to create it. The full discussion is in launchpad systemd answers.

edited Jul 22 '17 at 16:16

answered Aug 18 '16 at 03:57

WinEunuuchs2Unix

102,282

2

I tried this without success. As my Ubuntu 16.04 instance has the form of a docker container and I have not set up any users I am working as root, so I used the variable XDG_RUNTIME_DIR=/run/root/0, without success. Then I checked the folder /run and found that there is no subfolder /run/root. Is there anyway I can get a more verbose error message? I had a look at systemctl --help but couldn't see a way of getting detailed error messages. – Duncan Gravill Aug 18 '16 at 15:11
1

I am having the same issue and this also did not resolve my problem. Did you ever figure this one out @DuncanGravill – Roeland Sep 29 '16 at 14:57
3

@Roeland Yes. I asked a similar question on SO which had a stronger response. Also I recommend watching the Self-Paced tutorials on the Docker website. It is explained (slightly vaguely) in those videos how PID 1 which is usually systemd is replaced in a Docker container with the container Entrypoint. – Duncan Gravill Sep 30 '16 at 19:06
Brilliant, thanks! I needed this to start/manage a user unit from a system unit. – Adrian Günter May 08 '18 at 20:31
@DuncanGravill that's because the directory should be /run/user/0 and not /run/root/0 – am70 Oct 28 '20 at 16:06

score 14 · Answer 3 · edited Oct 15 '19 at 16:10

14

Just start the dbus service:

/etc/init.d/dbus start

edited Oct 15 '19 at 16:10

Eliah Kagan

117,780

answered Oct 15 '19 at 13:55

exud

309

1

I am building a custom container solution and ran into the problem that pihole would not install, complaining about systemd not being used as init system. Manually starting dbus did resolve this :) – Tox Apr 03 '23 at 21:07

score 9 · Answer 4 · answered Jun 23 '18 at 16:00

9

If you're getting this error in the Windows Subsystem for Linux (WSL), I've found it's because Docker is unsupported. This is due to lack of cgroups and other prerequisites.

answered Jun 23 '18 at 16:00

ijustlovemath

617

score 4 · Answer 5 · edited Jun 12 '20 at 14:37

4

Try this:

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

or

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

will be same result.

Here I get from the doc of Docker:

By default, Docker containers are “unprivileged” and cannot, for example, run a Docker daemon inside a Docker container. This is because by default a container is not allowed to access any devices, but a “privileged” container is given access to all devices (see the documentation on cgroups devices).

When the operator executes docker run --privileged, Docker will enable access to all devices on the host as well as set some configuration in AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host. Additional information about running with --privileged is available on the Docker Blog.

edited Jun 12 '20 at 14:37

Community

1

answered May 09 '18 at 07:42

sonjaya sonjaya

59

2

Could you explain your command and the difference to the accepted question? – Melebius May 10 '18 at 09:55
Welcome to AskUbuntu! Thank you for trying to help! A quick review of the documentation leads me to believe you may have made an error or 2 in this command. If you would be so kind as to [edit] it and explain what you are doing and how it solves the problem, ping me and I'll come back and give you an upvote! – Elder Geek May 10 '18 at 23:13
When you say images_docker, do you mean the vanilla ubuntu:16.04? Or something else? – Parth Shah Oct 04 '18 at 20:15

score 2 · Answer 6 · answered May 30 '17 at 03:54

2

You may not be running systemd, which is the default implementation of init on 16.04. If you upgraded from 14.04, you are most likely still running upstart, and the result of running the systemctl command is the output you got.

See my answer at systemctl : comand not found 16.04 server for more.

answered May 30 '17 at 03:54

Hugh Buntu

419

But this an Ubuntu container, which by default doesn't have systemd and wouldn't have upstart. – Stefan Lasiewski Aug 30 '17 at 22:21
what? ubuntu has systemd by default – knocte Jan 30 '18 at 02:36
1

Stefan: I believe you are correct in the case of Docker. – Hugh Buntu Jul 06 '18 at 21:08
knocte: my comment covers the case of upgrading from 14.04 (Upstart) to 16.04 (systemd). When performing the version upgrade, Upstart is not replaced with systemd for understandable reasons (like: not breaking the system). In retrospect, I realize the release upgrade process wouldn't be used in Docker. See the link I called out.
I see that a number of answers and comments fail to consider the specific case of Docker, and I'll look for that when answering in the future.
– Hugh Buntu Jul 06 '18 at 21:17

score 2 · Answer 7 · answered Jan 19 '18 at 16:29

2

I was getting the exact same error and then I run it successfully with sudo

sudo systemctl status ssh

answered Jan 19 '18 at 16:29

Saif

249

1

you shouldn't need sudo for that. Seems like a coincidence. Can you please re-test? – Zanna Jan 19 '18 at 16:54
2

@Zanna 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 – Saif Jan 19 '18 at 18:43
Why -1? I just posted what worked for me. – Saif Jan 19 '18 at 18:44
downvote was not mine... – Zanna Jan 19 '18 at 19:37
1

The question is about getting the systemctl status ssh command to run in the ubuntu:16.04 docker container. SSH is not installed in that container by default. You also don't need sudo to run these commands in a docker container. Normal best practices in permission management are different between docker containers and normal OS's. I assume your answer is for normal Ubuntu installation. – Dan Jun 22 '20 at 15:58

score -3 · Answer 8 · answered Jan 08 '18 at 12:06

-3

Inside docker container, I think you can update-rc.d if you are still struggling with systemd. I tried with update-rd.c and it works.

answered Jan 08 '18 at 12:06

NEERAJ SWARNKAR

176

this is for system V not systemd – Efren Aug 05 '20 at 01:53

systemctl failed to connect to bus - docker ubuntu:16.04 container

8 Answers8

Linked