Podman running container limits
from zeGoomba@programming.dev to selfhosted@lemmy.world on 04 Dec 06:44
https://programming.dev/post/22447000

I was wondering, Do you know of a limit on how many rootless conrainers can one run on a linux host?

Running fedora server, I have resources but once I pass about 15 containers podman starts to hang and crash.

I then need to manually delete the storage folder under ~./local/share/… for podman to work again.

It might be related to user ns keep-id flag.

#selfhosted

threaded - newest

droopy4096@lemmy.ca on 04 Dec 06:51 next collapse

I’m not convinced what you run into is a specific podman issue. It’s a resource issue and configuration issue likely. “vanila” podman with proper rootless containers will run as much workload as machine can handle from my experience. My company costomers seem to be running production workloads with it just fine.

Oh wait, by rootless container you really meant running podman rootless? still don’t see an issue though. What specifically are you doing? I mean, what’s the configuration and what’s the workload?

zeGoomba@programming.dev on 05 Dec 11:46 collapse

My config is nothing special. Running all containers as user 1000 via qadlets. Sporadically, I get:

Dec 05 13:40:27 home-lab systemd-coredump[200811]: [🡕] Process 200795 (podman) of user 1000 dumped core.

                                                   Module libbz2.so.1 from rpm bzip2-1.0.8-18.fc40.x86_64
                                                   Module libsepol.so.2 from rpm libsepol-3.7-2.fc40.x86_64
                                                   Module libpcre2-8.so.0 from rpm pcre2-10.44-1.fc40.x86_64
                                                   Module libcap-ng.so.0 from rpm libcap-ng-0.8.4-4.fc40.x86_64
                                                   Module libgpg-error.so.0 from rpm libgpg-error-1.49-1.fc40.x86_64
                                                   Module libpam_misc.so.0 from rpm pam-1.6.1-4.fc40.x86_64
                                                   Module libpam.so.0 from rpm pam-1.6.1-4.fc40.x86_64
                                                   Module libattr.so.1 from rpm attr-2.5.2-3.fc40.x86_64
                                                   Module libacl.so.1 from rpm acl-2.3.2-1.fc40.x86_64
                                                   Module libcrypt.so.2 from rpm libxcrypt-4.4.36-10.fc40.x86_64
                                                   Module libeconf.so.0 from rpm libeconf-0.6.2-2.fc40.x86_64
                                                   Module libsemanage.so.2 from rpm libsemanage-3.7-2.fc40.x86_64
                                                   Module libselinux.so.1 from rpm libselinux-3.7-5.fc40.x86_64
                                                   Module libaudit.so.1 from rpm audit-4.0.2-1.fc40.x86_64
                                                   Module libseccomp.so.2 from rpm libseccomp-2.5.5-1.fc40.x86_64
                                                   Module podman from rpm podman-5.3.1-1.fc40.x86_64
                                                   Stack trace of thread 200805:
                                                   #0  0x0000558789bfa4a1 runtime.raise.abi0 (podman + 0x934a1)
                                                   #1  0x0000558789bd6cc8 runtime.sigfwdgo (podman + 0x6fcc8)
                                                   #2  0x0000558789bd51a5 runtime.sigtrampgo (podman + 0x6e1a5)
                                                   #3  0x0000558789bfa7a9 runtime.sigtramp.abi0 (podman + 0x937a9)
                                                   #4  0x00007efdbc0cad00 __restore_rt (libc.so.6 + 0x40d00)
                                                   #5  0x0000558789bfa4a1 runtime.raise.abi0 (podman + 0x934a1)
                                                   #6  0x0000558789bbda26 runtime.fatalpanic (podman + 0x56a26)
                                                   #7  0x0000558789bbc998 runtime.gopanic (podman + 0x55998)
                                                   #8  0x0000558789bd64d8 runtime.sigpanic (podman + 0x6f4d8)
                                                   #9  0x000055878a5a7842 github.com/containers/storage.(*layerStore).load (podman + 0xa40842)
                                                   #10 0x000055878a5a9608 github.com/containers/storage.(*store).newLayerStore (podman + 0xa42608)
                                                   #11 0x000055878a5bc7dd github.com/containers/storage.(*store).getLayerStoreLocked (podman + 0xa557dd)
                                                   #12 0x000055878a5bc935 github.com/containers/storage.(*store).getLayerStore (podman + 0xa55935)
                                                   #13 0x000055878a5cc451 github.com/containers/storage.(*store).Mounted (podman + 0xa65451)
<
Voroxpete@sh.itjust.works on 04 Dec 10:48 next collapse

The practical limit to the number of containers you can run on one system is in the high hundreds or more thousands, depending on how you configure some things, and your available hardware. It’s certainly more than you’ll even use unless you get into some auto-scaling swarm config stuff.

The issue is more about resource limits, and access to shared resources. I’d start by trying to figure out if there are certain specific containers that don’t play well together. Bring your setup online slowly, one container at a time, and take note of when things start to get funky. Then start testing combinations of those specific containers. See if there’s one you can remove from the mix that suddenly makes things more stable.

zeGoomba@programming.dev on 09 Dec 08:41 collapse

Small update.

It seems to be caused by UserNS=keep-id . when adding it to an image with a lot of files, podman hangs for a while, then crashes when doind its chown. This causes some layers to be invalid.