Podman: container does not start because of `systemd support for managing cgroups is not available`

[git001]

BUG REPORT:

Description

When I run podman on a fresh installed ubuntu 18 then I get the following error.

Command:

podman run -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d                     -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf  -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/                     registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd

Error:

container create failed: systemd cgroup flag passed, but systemd support for managing cgroups is not available
: internal libpod error

Steps to reproduce the issue:

1. Setup droplet
   doctl compute droplet create secrets --region fra1 --image ubuntu-18-04-x64 --ssh-keys 7008657,13468054 --size s-4vcpu-8gb --wait --enable-private-networking

2. Build Podman as desribed in readme

3. run the command

podman run -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d                     -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf  -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/                     registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd

Describe the results you received:

container create failed: systemd cgroup flag passed, but systemd support for managing cgroups is not available
: internal libpod error

Describe the results you expected:
I expect a running container

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

Output of podman version:

Version:       0.9.4-dev
Go Version:    go1.10.1
OS/Arch:       linux/amd64

Output of podman info:

podman info
host:
  Conmon:
    package: Unknown
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: 3b00e355d5247f7235b9612799554f4535a1e547'
  MemFree: 5373353984
  MemTotal: 8364032000
  OCIRuntime:
    package: Unknown
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc5+dev
      commit: 00dc70017d222b178a002ed30e9321b12647af2d
      spec: 1.0.0
  SwapFree: 0
  SwapTotal: 0
  arch: amd64
  cpus: 4
  hostname: secrets
  kernel: 4.15.0-30-generic
  os: linux
  uptime: 1h 55m 23.39s (Approximately 0.04 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
store:
  ContainerStore:
    number: 7
  GraphDriverName: overlay
  GraphOptions: []
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
  ImageStore:
    number: 1
  RunRoot: /var/run/containers/storage

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

• Digital Ocean droplet
• lsb_release -a

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

[mheon]

Hm. It looks like 18.04 should have systemd as PID1, so I'm confused as to why it can't find it...

Can you verify that your init is systemd? If systemctl status succeeds as root, it's definitely there...

For now, you can create /etc/containers/libpod.conf based on the one in the root of this repository, and set cgroup manager to cgroupfs instead of systemd.

[mheon]

This could potentially be a permissions issue or similar. I'll see if I can reproduce later.

[mheon]

Oh, one more thing: is this running as rootless? Or with root?

[git001]

it runs as root

[mheon]

Going to take a look into this today

[mheon]

Alright, I can reproduce. Systemd is definitely running, so we may not have permission to talk to it over dbus?

[mheon]

Nevermind, it's an error in the instructions. runc does not build in systemd cgroup support if it is built statically.

[mheon]

Confirmed. Building runc without static works perfectly.

[mheon]

@git001 I opened #1562 to update our docs on this. Can you try rebuilding/reinstalling runc with the new make command and see if that fixes things?

[git001]

@mheon yep after removing the static and selinux from #1562 the container runs as root but not as normal user

al@secrets:~$ podman run -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d                     -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf  -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/                     me2digital/caddy
error creating libpod runtime: exit status 125

[mheon]

Going to reopen because of the rootless issue. I suspect it might be missing kernel patches, though - we have a few included in Fedora for rootless that haven't made it into mainline, last I checked.

[q2dg]

I have Fedora 28 updated to kernel v4.18.13-200 and I still get the error "error creating libpod runtime: exit status 1" when executing podman as a regular user.

[rhatdan]

You will not be able to run systemd as a container in non root, because it expects to be able to manage the cgroup and usernamespace and cgroups are not supported together at this time, and we have no means of mounting a cgroup file system in user namespace.

[mskarbek]

Can we expect that systemd will ever work in rootless? Judging by your comment @rhatdan that would require some heavy kernel namespace work or systemd would have to be able to give up cgroup management in a container.

[mheon]

There is a possibility that it will be workable once V2 CGroups are ready for use with containers, but I don't know exactly when that will happen, or whether it will require additional work to get allow systemd to use the CGroup delegation allowed by V2

[mskarbek]

So, for now, this has to be closed to allow further work on systemd? https://github.com/opencontainers/runc/issues/654

[knusbaum]

Does podman require systemd, or is there a way to run podman on an alternative init system?

[mheon]

For CGroup management, you can set Podman to use the cgroupfs driver
instead of the systemd one, which should let us run on systems without
systemd as PID1. I don't think we have any specific requirement for an init
system otherwise

On Tue, Nov 27, 2018, 02:52 Kyle Nusbaum <[email protected] wrote:

Does podman require systemd, or is there a way to run podman on an
alternative init system?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/containers/libpod/issues/1534#issuecomment-441960753,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHYHCGyqtP29nOq2XKPi0ljOXFZ3ic-bks5uzO9HgaJpZM4W3A3p
.

[rhatdan]

Correct there should be no requirement for systemd if you change to using cgroupfs. If there is, then it is a bug.

[knusbaum]

Thanks. Not to derail the thread, but does cgroupfs only work as root user? I can launch stuff with podman as root with --cgroup-manager=cgroupfs but any other user gets error creating libpod runtime: exit status 1

[mheon]

Should work everywhere - systemd is the one that has issues as non-root. It's probably another issue with rootless Podman.

[rhatdan]

Until we have delegation of cgroups systemd will only work as root.