DietPi-Software | Podman

[isarrider]

has anybody looked in podman on DietPi so far?
it is on my plan to look into it...

[Joulinar]

not that I'm aware of.

[MichaIng]

Adding the GitHub link: https://github.com/containers/podman

[queeup]

Personally I prefer podman.

[isarrider]

from many POVs, podman is superior...
If I find time, Ill investigate a bit more
and post my findings here...

[Joulinar]

what system you are running? Because on my R5S, it just requires podman as well as dbus to be installed only. No need to manage the cgroupv2 error. I guess it's related to kernel version.

[radekbenkel]

@Joulinar sorry, forgot to mention it above :)

 ─────────────────────────────────────────────────────
 DietPi v8.10.2 : 18:39 - Mon 10/24/22
 ─────────────────────────────────────────────────────
 - Device model : RPi 3 Model B (aarch64)
 - CPU temp : 36 °C / 96 °F : Cool runnings
 ─────────────────────────────────────────────────────
 
 $ uname -a 
 Linux DietPi 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux

EDIT: tried on VirtualBox's VM and got similar errors, cgroupv2 and newuidmap missing.

Maybe in your case other packages added what's required and you can use cgroupManager: systemd instead of cgroupManager: cgroupfs like in my case (based on podman info output) 🤔

[Joulinar]

ok I tested on the same device and it's working ootb

apt install podman dbus
systemctl enable dbus
systemctl start dbus
podman run -dt -p 8080:80/tcp docker.io/library/httpd

and podman ps returns following

root@DietPi:~# podman ps
CONTAINER ID  IMAGE                           COMMAND           CREATED             STATUS                 PORTS                 NAMES
dc634e1cc46d  docker.io/library/httpd:latest  httpd-foreground  About a minute ago  Up About a minute ago  0.0.0.0:8080->80/tcp  jovial_edison
root@DietPi:~#

[radekbenkel]

@Joulinar ok, now it hit me with idea why we have different behavior.

From your examples: root@DietPi:~# podman ps ... root@DietPi ... root. I replicated your instructions as a root (on x86 VM) and indeed everything worked (with cgroupManager ended up being systemd).

My instructions were from a POV of non-root user, as one of the selling points of podman is ability to run rootless containers. My assumption is that's why I needed uidmap (for UID mapping) and slirp4netns (from package description: "User-mode networking for unprivileged network namespaces").

htop output for both cases seem to confirm my assumptions:

• as dietpi:

• as root:

Does it make sense? (again, my Linux-fu is far from being top-notch :)

[Joulinar]

most probably you are right on your assumption with the rootless user setup https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md

[Gibbz]

Im trying to setup podman on dietpi as rootless user. I'm having issues with environment variables.
I get the errors when using systemd in user mode:

systemctl --user daemon-reexec && systemctl --user daemon-reload

Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

Ive tried setting the variables in, but they always echo as blank....

/etc/environment
$HOME/.config/environment.d/60-bus-fix.conf 

[Gibbz]

Looks like it was a dropbear issue, changed to openssh!

[MichaIng]

Right, Dropbear has only limited PAM support, hence no automatic dbus/logind registration for user services.

[Gibbz]

So I've setup podman with a bunch of containers.
I'm having a real issue with jellyfin. The container keeps shutting down during library scans. Then it takes some time to come back up. The logs indicate systemd is shutting it down.....

Is dietpi doing some over optimisations with systemd to cause it to keep shutting down my podman services?

[Gibbz]

Thanks... dmesg doesnt show anything and the system has 16g of ram (no swap though).
I'll run it without systemd and see if that makes any difference.

[Gibbz]

Ok not sure what's going on. If I run using podman -d it works fine. But when using systemd it keeps getting terminated.

I'm pretty sure I've enabled linger, and it's not out of memory...

A strange thing I've noticed. If I login to cockpit and check the pod status it always says created less than a minute ago, and running less than a minute. Maybe the linger is not working. And the services are killed...

Edit: looks like linger didn't work. I've reenabled it and will try again!

[MichaIng]

Does it work when you start them as system services as root?

systemd-logind is unmasked/running?

[Gibbz]

Reenabling linger mode looks to have fixed the issue 👍 no problem since.
I don't know why the command didn't stick the first time when I set it up.

[MichaIng]

Okay so it was a user service thing then. To be honest, I have near zero experience with those, as I personally set up everything as system service with dedicated service user.

Just know that it generally requires logind registration, PAM, anf hence DBus for unprivileged users to spawn and access a user systemd instance, and that linger is needed to keep those user instances active after the session ended.