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

container does not start because of `systemd support for managing cgroups is not available` #1534

Open
git001 opened this Issue Sep 24, 2018 · 21 comments

Comments

Projects
None yet
6 participants
@git001
Copy link

git001 commented Sep 24, 2018

BUG REPORT:

[//]: # Uncomment only one, leave it on its own line:

[//]: kind bug

[//]: # kind feature

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

This comment has been minimized.

Copy link
Collaborator

mheon commented Sep 24, 2018

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 comment has been minimized.

Copy link
Collaborator

mheon commented Sep 24, 2018

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

@mheon mheon added the bug label Sep 24, 2018

@mheon

This comment has been minimized.

Copy link
Collaborator

mheon commented Sep 24, 2018

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

@git001

This comment has been minimized.

Copy link

git001 commented Sep 24, 2018

it runs as root

@mheon

This comment has been minimized.

Copy link
Collaborator

mheon commented Sep 27, 2018

Going to take a look into this today

@mheon

This comment has been minimized.

Copy link
Collaborator

mheon commented Sep 27, 2018

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

@mheon

This comment has been minimized.

Copy link
Collaborator

mheon commented Sep 27, 2018

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

@mheon

This comment has been minimized.

Copy link
Collaborator

mheon commented Sep 27, 2018

Confirmed. Building runc without static works perfectly.

@mheon

This comment has been minimized.

Copy link
Collaborator

mheon commented Sep 27, 2018

@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

This comment has been minimized.

Copy link

git001 commented Sep 27, 2018

@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

This comment has been minimized.

Copy link
Collaborator

mheon commented Oct 2, 2018

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.

@mheon mheon reopened this Oct 2, 2018

@q2dg

This comment has been minimized.

Copy link

q2dg commented Oct 15, 2018

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

This comment has been minimized.

Copy link
Member

rhatdan commented Oct 15, 2018

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

This comment has been minimized.

Copy link

mskarbek commented Oct 17, 2018

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

This comment has been minimized.

Copy link
Collaborator

mheon commented Oct 17, 2018

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

This comment has been minimized.

Copy link

mskarbek commented Oct 17, 2018

So, for now, this has to be closed to allow further work on systemd? opencontainers/runc#654

@knusbaum

This comment has been minimized.

Copy link

knusbaum commented Nov 27, 2018

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

@mheon

This comment has been minimized.

Copy link
Collaborator

mheon commented Nov 27, 2018

@rhatdan

This comment has been minimized.

Copy link
Member

rhatdan commented Nov 27, 2018

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

@knusbaum

This comment has been minimized.

Copy link

knusbaum commented Nov 27, 2018

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

This comment has been minimized.

Copy link
Collaborator

mheon commented Nov 27, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment