Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

podman complains about missing dbus-launch -- but I don't want to install a full desktop environment #9353

Closed
asottile opened this issue Feb 12, 2021 · 25 comments · Fixed by #9407
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@asottile
Copy link
Contributor

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

When I run any podman command as another user, I get this output:

$ sudo -u pcrunner podman ps
WARN[0000] Failed to add podman to systemd sandbox cgroup: exec: "dbus-launch": executable file not found in $PATH 
CONTAINER ID  IMAGE   COMMAND  CREATED  STATUS  PORTS   NAMES

dbus-launch on ubuntu is provided by the dbus-x11 package which pulls in a full x11 environment which I absolutely do not need on a headless server.

Steps to reproduce the issue:

  1. run any podman command as another user

Describe the results you received:

see above

Describe the results you expected:

no extraneous output

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

$ sudo -u pcrunner podman version
WARN[0000] Failed to add podman to systemd sandbox cgroup: exec: "dbus-launch": executable file not found in $PATH 
Version:      3.0.0
API Version:  3.0.0
Go Version:   go1.15.2
Built:        Thu Jan  1 00:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

$ sudo -u pcrunner podman info --debug
WARN[0000] Failed to add podman to systemd sandbox cgroup: exec: "dbus-launch": executable file not found in $PATH 
host:
  arch: amd64
  buildahVersion: 1.19.2
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.26, commit: '
  cpus: 1
  distribution:
    distribution: ubuntu
    version: "20.04"
  eventLogger: journald
  hostname: ip-172-31-79-82
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 2000
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 2000
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
  kernel: 5.4.0-1037-aws
  linkmode: dynamic
  memFree: 82300928
  memTotal: 1026150400
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17.6-58ef-dirty
      commit: fd582c529489c0738e7039cbc036781d1d039014
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /tmp/podman-run-2000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    selinuxEnabled: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.1.8
      commit: unknown
      libslirp: 4.3.1-git
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.4.3
  swapFree: 0
  swapTotal: 0
  uptime: 44m 35.93s
registries: {}
store:
  configFile: /home/pcrunner/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: 'fuse-overlayfs: /usr/bin/fuse-overlayfs'
      Version: |-
        fusermount3 version: 3.9.0
        fuse-overlayfs: version 1.4
        FUSE library version 3.9.0
        using FUSE kernel interface version 7.31
  graphRoot: /home/pcrunner/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /tmp/containers-user-2000/containers
  volumePath: /home/pcrunner/.local/share/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 0
  BuiltTime: Thu Jan  1 00:00:00 1970
  GitCommit: ""
  GoVersion: go1.15.2
  OsArch: linux/amd64
  Version: 3.0.0

Package info (e.g. output of rpm -q podman or apt list podman):

$ apt list podman-rootless
Listing... Done
podman-rootless/unknown,now 100:3.0.0-1 amd64 [installed]
podman-rootless/unknown 100:3.0.0-1 arm64
podman-rootless/unknown 2.2.1~4 armhf
podman-rootless/unknown 100:3.0.0-1 s390x

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

AWS

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Feb 12, 2021
@vrothberg
Copy link
Member

vrothberg commented Feb 15, 2021

Thanks for reaching out!

Podman uses the systemd cgroup manager by default. You could change it to cgroupfs on the CLI via --cgroup-manager=cgroupfs or you tweak /usr/share/containers/containers.conf and set

[engine]
cgroup_manager="cgroupfs"

@vrothberg
Copy link
Member

Please let me know if that works for you.

@rhatdan
Copy link
Member

rhatdan commented Feb 15, 2021

The containers.conf change should be made in /etc/containers/containers.conf

@asottile
Copy link
Contributor Author

that changes the error message but doesn't fix it:

$ sudo -u pcrunner podman run --rm -ti ubuntu:focal echo
WARN[0000] Failed to add podman to systemd sandbox cgroup: dbus: couldn't determine address of session bus 

@asottile
Copy link
Contributor Author

and actually, if I install dbus-x11 (which I don't want to) it still doesn't work (this is with the default container config):

$ sudo -u pcrunner podman run --rm -ti ubuntu:focal echo
WARN[0000] Failed to add podman to systemd sandbox cgroup: dbus: couldn't determine address of session bus 

@vrothberg
Copy link
Member

vrothberg commented Feb 15, 2021

Can you try with sudo --login -u? It looks like the systemd session of the pcrunner user is not complete.

@asottile
Copy link
Contributor Author

It's meant to be a service user only -- does podman require a full login session?

@asottile
Copy link
Contributor Author

(fwiw, this prints -- as I expect for service users):

$ sudo --login -u pcrunner podman run --rm -ti ubuntu:focal echo
This account is currently not available.

@al-cheb
Copy link

al-cheb commented Feb 15, 2021

I can reproduce the same behavior on Ubuntu 18.04. Starting with podman 3.0.0 one of dependence is dbus-user-session which breaks our CI with Az.Accounts powershell module. Is it possible to eliminate installation the dbus-user-session pkg?

$ pwsh -command "Import-Module Az.Accounts"
** Message: 17:43:58.624: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files
** Message: 17:43:58.630: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files
** Message: 17:43:58.633: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files 

journalclt -e

Feb 15 17:43:58  powershell[16735]: Microsoft.Identity.Client.Extensions.TraceSource Error: 0 :
Feb 15 17:43:58  powershell[16735]: [MSAL.Extension][2021-02-15T17:43:58.6249328Z] An error was encountered while saving secret to keyring in the MsalCacheStorage domain:'95' co
Feb 15 17:43:58  powershell[16735]: Microsoft.Identity.Client.Extensions.TraceSource Error: 0 :
Feb 15 17:43:58  powershell[16735]: [MSAL.Extension][2021-02-15T17:43:58.6308996Z] An error was encountered while reading secret from keyring in the MsalCacheStorage domain:'95'
Feb 15 17:43:58  powershell[16735]: Microsoft.Identity.Client.Extensions.TraceSource Error: 0 :
Feb 15 17:43:58  powershell[16735]: [MSAL.Extension][2021-02-15T17:43:58.6340969Z] An error was encountered while clearing secret from keyring in the MsalCacheStorage domain:'95

lsb_release -a

No LSB modules are available.
Distributor ID:Ubuntu
Description:Ubuntu 18.04.5 LTS
Release:18.04
Codename:bionic

Warnings don't reproduce with sudo:

$ sudo --login -u test pwsh -command "Import-Module Az.Accounts;Get-Module"

ModuleType Version    PreRelease Name                                ExportedCommands
---------- -------    ---------- ----                                ----------------
Script     2.2.5                 Az.Accounts                         {Add-AzEnvironment, Clear-AzContext, Clear-AzDefault, Connect-AzAccount…}

@ocafebabe
Copy link

I'm observing the same behaviour with a fresh podman 3.0.0 install on Ubuntu 20.04...

I never had this issue with podman 2.2.1 on my other Ubuntu 20.04 servers, what has been changed in the latest release?

@asottile
Copy link
Contributor Author

I'm observing the same behaviour with a fresh podman 3.0.0 install on Ubuntu 20.04...

I never had this issue with podman 2.2.1 on my other Ubuntu 20.04 servers, what has been changed in the latest release?

I believe the reason it is just showing up now is the default log level changed from ERROR => WARN in 3.0.0

@ocafebabe
Copy link

I'm observing the same behaviour with a fresh podman 3.0.0 install on Ubuntu 20.04...
I never had this issue with podman 2.2.1 on my other Ubuntu 20.04 servers, what has been changed in the latest release?

I believe the reason it is just showing up now is the default log level changed from ERROR => WARN in 3.0.0

This really sucks because now I get false-positive alerts whenever podman is invoked as this gets printed during crontab task executions.

BTW my use case is similar to yours: service account (accessed using sudo -u xxxxx -i) running on headless servers.

@asottile
Copy link
Contributor Author

I'm currently hacking around the warning with --log-level error (in a commit that I hope to revert once this issue is fixed)

@rhatdan
Copy link
Member

rhatdan commented Feb 16, 2021

Are you saying that you changed the containers.conf to use cgroupfs for cgroup-manager, but you are still seeing it attempt to use dbus-launch?

@asottile
Copy link
Contributor Author

yes:

$ grep cgroup_manager /etc/containers/containers.conf
cgroup_manager = "cgroupfs"
$ sudo -u pcrunner podman run ubuntu:focal echo
WARN[0000] Failed to add podman to systemd sandbox cgroup: dbus: couldn't determine address of session bus 

@rhatdan
Copy link
Member

rhatdan commented Feb 16, 2021

What about the log_driver? Is this set to journald?

@rhatdan
Copy link
Member

rhatdan commented Feb 16, 2021

# events_logger = "journald"

@asottile
Copy link
Contributor Author

it's set to whatever the default is:

$ grep log_d -- /etc/containers/containers.conf 
# log_driver = "k8s-file"

@rhatdan
Copy link
Member

rhatdan commented Feb 16, 2021

Uncomment that line and see if the problem goes away.

@asottile
Copy link
Contributor Author

no dice

$ grep -E '(cgroup_|log_d)' /etc/containers/containers.conf 
log_driver = "k8s-file"
cgroup_manager = "cgroupfs"
$ sudo -u pcrunner podman run ubuntu:focal echo
WARN[0000] Failed to add podman to systemd sandbox cgroup: dbus: couldn't determine address of session bus 

@rhatdan
Copy link
Member

rhatdan commented Feb 17, 2021

func (ic *ContainerEngine) SetupRootless(_ context.Context, cmd *cobra.Command) error {
	// do it only after podman has already re-execed and running with uid==0.
	if os.Geteuid() == 0 {
		ownsCgroup, err := cgroups.UserOwnsCurrentSystemdCgroup()
		if err != nil {
			logrus.Warnf("Failed to detect the owner for the current cgroup: %v", err)
		}
		if !ownsCgroup {
			conf, err := ic.Config(context.Background())
			if err != nil {
				return err
			}

			initCommand, err := ioutil.ReadFile("/proc/1/comm")
			// On errors, default to systemd
			runsUnderSystemd := err != nil || strings.TrimRight(string(initCommand), "\n") == "systemd"

			unitName := fmt.Sprintf("podman-%d.scope", os.Getpid())
			if runsUnderSystemd || conf.Engine.CgroupManager == config.SystemdCgroupsManager {
				if err := utils.RunUnderSystemdScope(os.Getpid(), "user.slice", unitName); err != nil {
					logrus.Warnf("Failed to add podman to systemd sandbox cgroup: %v", err)
				}
			}
		}
		return nil
	}
...

@rhatdan
Copy link
Member

rhatdan commented Feb 17, 2021

@giuseppe WDYT? Should we handle the lack of dbus_launch better, IE Not Warn?

@ocafebabe
Copy link

@giuseppe WDYT? Should we handle the lack of dbus_launch better, IE Not Warn?

Could you please explain why "dbus_launch" is important for podman?

@vrothberg
Copy link
Member

It's meant to be a service user only -- does podman require a full login session?

It'll work without a full login session but the storage paths may differ when logging in. Since you intend it to be service-only user, it's good.

@giuseppe WDYT? Should we handle the lack of dbus_launch better, IE Not Warn?

I think it should be a debug log.

giuseppe added a commit to giuseppe/libpod that referenced this issue Feb 17, 2021
if the current process could not be moved to a different systemd
cgroup do not raise a warning but debug message.

Closes: containers#9353

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
@giuseppe
Copy link
Member

dbus-launch is used by github.com/godbus/dbus/v5/conn_other.go.

I am fine to downgrade the warning to a debug message: opened a PR: #9407

giuseppe added a commit to giuseppe/libpod that referenced this issue Feb 17, 2021
if the current process could not be moved to a different systemd
cgroup do not raise a warning but debug message.

Closes: containers#9353

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe added a commit to giuseppe/libpod that referenced this issue Feb 17, 2021
if the current process could not be moved to a different systemd
cgroup do not raise a warning but debug message.

[NO TESTS NEEDED]
Closes: containers#9353

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe added a commit to giuseppe/libpod that referenced this issue Feb 17, 2021
if the current process could not be moved to a different systemd
cgroup do not raise a warning but debug message.

[NO TESTS NEEDED]
Closes: containers#9353

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
mheon pushed a commit to mheon/libpod that referenced this issue Feb 18, 2021
if the current process could not be moved to a different systemd
cgroup do not raise a warning but debug message.

[NO TESTS NEEDED]
Closes: containers#9353

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants