docs
docs copied to clipboard
dockerd-rootless-setuptool.sh install fails to detect systemd unless $XDG_RUNTIME_DIR is set first
Problem description
When I follow the rootless installation instructions on Linux Mint 20 (based on Ubuntu 20.04) it fails to detect systemd:
dockerd@emvc:~$ dockerd-rootless-setuptool.sh install
[INFO] systemd not detected, dockerd-rootless.sh needs to be started manually:
PATH=/usr/bin:/sbin:/usr/sbin:$PATH dockerd-rootless.sh
[INFO] Creating CLI context "rootless"
Successfully created context "rootless"
[INFO] Make sure the following environment variables are set (or add them to ~/.bashrc):
# WARNING: systemd not found. You have to remove XDG_RUNTIME_DIR manually on every logout.
export XDG_RUNTIME_DIR=/home/dockerd/.docker/run
export PATH=/usr/bin:$PATH
export DOCKER_HOST=unix:///home/dockerd/.docker/run/docker.sock
Setting XDG_RUNTIME_DIR as the script suggests does not help. systemctl --user
still fails with "Failed to connect to bus: No such file or directory". Following this StackOverflow answer, what works is setting XDG_RUNTIME_DIR to /run/user/... before running dockerd-rootless-setuptool.sh install
:
export XDG_RUNTIME_DIR=/run/user/$(id -u)
dockerd-rootless-setuptool.sh install
(I actually added it to .bash_profile - that would be helpful to add, too. Unlike .bashrc, .bash_profile gets loaded when using sudo -iu dockerd
)
(I also enabled lingering for the user first, following that answer, but I don't know if that was strictly necessary.)
Problem location
https://docs.docker.com/engine/security/rootless/#install
Suggestions for a fix
I'm not sure if this is a problem with the documentation or the dockerd-rootless-setuptool.sh script itself could handle this better, but assuming the script is not changed, it would help if the documentation page suggested setting XDG_RUNTIME_DIR before running the script, or at least in the troubleshooting section if you get
[INFO] systemd not detected, dockerd-rootless.sh needs to be started manually
Is this possibly an issue with how you are switching to the non-privileged user prior to running the installation? I just ran into this same issue when installing, and found various recommendations related to setting XDG_RUNTIME_DIR
manually. Then I found the following: https://serverfault.com/a/1047069 . This discusses a more general issue of systemctl --user
not working correctly under certain conditions. Specifically:
If you login in the system using either of
- graphical session
- login on terminal (username and password)
- ssh
then the PAM machinery will call pam_systemd, and this will setup all needed hooks to use systemctl; if you switch user using sudo or su, this will not happen.
(emphasis mine)
In my case, I was switching to the user using su mydockeruser -
, and was receiving the same error you were regarding systemd
not being detected. However if I ssh in as mydockeruser
directly, the installer works just fine without the error.
In other words:
Switching to user mydockeruser
from another user (using su
), systemctl --user
does not work properly:
otheruser@myhostname:~$ su mydockeruser -
Password:
mydockeruser@myhostname:~$ systemctl --user status
Failed to connect to bus: Operation not permitted (consider using --machine=<user>@.host --user to connect to bus of other user)
Connecting directly as mydockeruser (via ssh), systemctl --user
works properly:
> ssh mydockeruser@myhostname
mydockeruser@myhostname's password:
Linux myhostname 5.10.0-16-amd64 #1 SMP Debian 5.10.127-2 (2022-07-23) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
mydockeruser@myhostname:~$ systemctl --user status
● myhostname
State: running
Jobs: 0 queued
Failed: 0 units
Since: Thu 2022-08-04 16:23:36 CDT; 4s ago
CGroup: /user.slice/user-1001.slice/[email protected]
├─app.slice
│ ├─gvfs-goa-volume-monitor.service
│ │ └─1641 /usr/libexec/gvfs-goa-volume-monitor
│ ├─tracker-store.service
│ │ └─1660 /usr/libexec/tracker-store
│ ├─pulseaudio.service
│ │ └─1577 /usr/bin/pulseaudio --daemonize=no --log-target=journal
│ ├─gvfs-daemon.service
│ │ ├─1602 /usr/libexec/gvfsd
│ │ └─1614 /usr/libexec/gvfsd-fuse /run/user/1001/gvfs -f
│ ├─gvfs-udisks2-volume-monitor.service
│ │ └─1621 /usr/libexec/gvfs-udisks2-volume-monitor
│ ├─tracker-extract.service
│ │ └─1579 /usr/libexec/tracker-extract
│ ├─gvfs-gphoto2-volume-monitor.service
│ │ └─1633 /usr/libexec/gvfs-gphoto2-volume-monitor
│ ├─pipewire.service
│ │ ├─1576 /usr/bin/pipewire
│ │ └─1593 /usr/bin/pipewire-media-session
│ ├─dbus.service
│ │ ├─1592 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfi>
│ │ ├─1645 /usr/libexec/goa-daemon
│ │ └─1653 /usr/libexec/goa-identity-service
│ ├─tracker-miner-fs.service
│ │ └─1580 /usr/libexec/tracker-miner-fs
│ ├─gvfs-mtp-volume-monitor.service
│ │ └─1637 /usr/libexec/gvfs-mtp-volume-monitor
│ └─gvfs-afc-volume-monitor.service
│ └─1628 /usr/libexec/gvfs-afc-volume-monitor
└─init.scope
├─1561 /lib/systemd/systemd --user
└─1562 (sd-pam)
https://rootlesscontaine.rs/getting-started/common/login/
Most Rootless Containers implementations need the $XDG_RUNTIME_DIR environmental variable to be set. When the environment variable is not set, features related to systemd and cgroups are unlikely to work properly.
The value is typically set to /run/user/$UID automatically by systemd or elogind on logging into the host.
Run the following command to confirm:
$ echo $XDG_RUNTIME_DIR /run/user/1000 The $XDG_RUNTIME_DIR environmental variable is set when:
Logged in as a non-root user via the graphic console . Logged in as a non-root user via ssh
@ . Logged in as the root, and then switched to a non-root user via machinectl shell @ . The environmental variable is not set when: Logged in as the root, and then switched to a non-root user via su -l
Logged in as the root, and then switched to a non-root user via sudo -u Logged in as the root, and then switched to a non-root user via ksu
TL;DR
Don’t use su and sudo for switching from root to non-root.
Use machinectl shell
@ or ssh @localhost instead.
In my case, I was switching to the user using
su mydockeruser -
, and was receiving the same error you were regardingsystemd
not being detected. However if I ssh in asmydockeruser
directly, the installer works just fine without the error.In other words:
Switching to user
mydockeruser
from another user (usingsu
),systemctl --user
does not work properly:
I experienced the same problem. I used su to switch to my non-root user and got that error. Using ssh as the same user worked flawlessly. Maybe it would be helpful to add that hint to the error message.
Hi, I solved is to make a file /etc/profile.d/docker.sh with the content:
[[ -S /run/user/${UID}/docker.sock ]] && { export XDG_RUNTIME_DIR=/run/user/${UID} export PATH=/usr/bin:$PATH export DOCKER_HOST=unix:///run/user/${UID}/docker.sock }
After a new 'su -
Instead of ssh
, or the other "workarounds" above, you could also try to start an interactive login session using machinectl
:
sudo machinectl shell testuser@
You might need to install this package first: sudo apt install systemd-container
I had the same issue trying to install docker rootless in a new user in my server.
My workaround was:
sudo loginctl enable-linger <username>
sudo reboot
After that, the user logged in again and found that XDG_RUNTIME_DIR
was defined and dockerd-rootless-setuptool.sh install
worked fine this time.
Hi, I solved is to make a file /etc/profile.d/docker.sh with the content:
[[ -S /run/user/${UID}/docker.sock ]] && { export XDG_RUNTIME_DIR=/run/user/${UID} export PATH=/usr/bin:$PATH export DOCKER_HOST=unix:///run/user/${UID}/docker.sock }
After a new 'su - ' it works for me. Hopefully I can help someone else with this solution.
The last command in curly brackets should have ;
, as { export XDG_RUNTIME_DIR=/run/user/${UID} export PATH=/usr/bin:$PATH export DOCKER_HOST=unix:///run/user/${UID}/docker.sock; }
There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale
comment.
If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.
Prevent issues from auto-closing with a /lifecycle frozen
comment.
/lifecycle stale
/remove-lifecycle stale
I just stumbled on this issue myself.
The following did solve it, but the problem is that this does not work out of the box.
https://unix.stackexchange.com/questions/587674/systemd-not-detected-dockerd-daemon-needs-to-be-started-manually/657714#657714