containers / podman

Podman: A tool for managing OCI containers and pods.
https://podman.io
Apache License 2.0
23.27k stars 2.37k forks source link

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

Closed asottile closed 3 years ago

asottile commented 3 years ago

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

vrothberg commented 3 years ago

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 commented 3 years ago

Please let me know if that works for you.

rhatdan commented 3 years ago

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

asottile commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

asottile commented 3 years ago

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

asottile commented 3 years ago

(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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

What about the log_driver? Is this set to journald?

rhatdan commented 3 years ago
# events_logger = "journald"
asottile commented 3 years ago

it's set to whatever the default is:

$ grep log_d -- /etc/containers/containers.conf 
# log_driver = "k8s-file"
rhatdan commented 3 years ago

Uncomment that line and see if the problem goes away.

asottile commented 3 years ago

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 commented 3 years ago
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 commented 3 years ago

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

ocafebabe commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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: https://github.com/containers/podman/pull/9407