Rootless fails to receive systemd slice shortly after boot about podman HOT 5 CLOSED

please provide the full command you are running.

That error happens with --cgroup-parent=$PARENT and $PARENT is not a systemd slice (i.e. it doesn't have a .slice suffix).

$ podman run --rm --cgroup-parent foo alpine true
Error: did not receive systemd slice as cgroup parent when using systemd to manage cgroups: invalid argument

from podman.

please provide the full command you are running.

That error happens with --cgroup-parent=$PARENT and $PARENT is not a systemd slice (i.e. it doesn't have a .slice suffix).

$ podman run --rm --cgroup-parent foo alpine true
Error: did not receive systemd slice as cgroup parent when using systemd to manage cgroups: invalid argument

I can reproduce it with a simple podman run --rm -it alpine:edge Incorrect, see next comment

from podman.

please provide the full command you are running.
That error happens with --cgroup-parent=$PARENT and $PARENT is not a systemd slice (i.e. it doesn't have a .slice suffix).

$ podman run --rm --cgroup-parent foo alpine true
Error: did not receive systemd slice as cgroup parent when using systemd to manage cgroups: invalid argument

I can reproduce it with a simple podman run --rm -it alpine:edge

Actually, no. Only in one pod of mine it seems to occur. I had just rebooted after making this post so my last comment was from memory, but I was able to check again now since it started occuring again:

[glitch@syndra ~]$ podman run --rm -it alpine:edge ash
/ #
[glitch@syndra ~]$ podman run --rm -it --pod glitch alpine:edge ash
Error: did not receive systemd slice as cgroup parent when using systemd to manage cgroups: invalid argument

Edit: Creating a new pod now and then running a container with --pod test works. Only this one pod does not work as expected.

[jens@syndra ~]$ sudo cat /etc/systemd/system/glitch-pod.service
[Unit]
Description=Create glitch pod

[Service]
Type=oneshot
User=glitch
Group=glitch
ExecStartPre=-/usr/bin/podman pod stop glitch
ExecStartPre=-/usr/bin/podman pod rm -f glitch
ExecStart=/usr/bin/podman pod create --name glitch -p 127.0.0.1:8080:80 -p 127.0.0.1:4443:443 -p 29418:29418
ExecStop=/usr/bin/podman pod rm -f glitch
ExecReload=/usr/bin/podman pod stop glitch
Restart=no
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

This is how the pod in question is created.

from podman.

[jens@syndra ~]$ sudo cat /etc/systemd/system/glitch-pod.service
[Unit]
Description=Create glitch pod

[Service]
Type=oneshot
User=glitch
Group=glitch
ExecStartPre=-/usr/bin/podman pod stop glitch
ExecStartPre=-/usr/bin/podman pod rm -f glitch
ExecStart=/usr/bin/podman pod create --name glitch -p 127.0.0.1:8080:80 -p 127.0.0.1:4443:443 -p 29418:29418
ExecStop=/usr/bin/podman pod rm -f glitch
ExecReload=/usr/bin/podman pod stop glitch
Restart=no
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

if you run with User= there is no systemd user session active for that user, so it ends up using the cgroupfs backend.

You can install the .service file under $HOME/.config/systemd/user/glitch-pod.service and avoid the User= attribute

from podman.

if you run with User= there is no systemd user session active for that user, so it ends up using the cgroupfs backend.

Ahh, thanks so much for this hint! I'll move to user units then :)

from podman.