toolbox does not change podman's /dev/shm size default, so that stays at 64 MB:
$ df -h /dev/shm
shm 63M 0 63M 0% /dev/shm
I often run browser integration tests in toolbox, and chromium regularly crashes as it runs out of memory.
This can be controlled by podman create --shm-size=0 (which disables the limit), or e. g. podman create --shm-size=512m. In the spirit of toolbox I'd suggest to simply use 0 as a default and not make this configurable.
Hi! I don't know what is the best solution, if is better to use unlimited value or a fixed value, I think is better to support the shm parameter size from the command arguments because it could handle multiple scenarios.
I could do the PR if you are agree on that solution @HarryMichal
This looks alright to me. I'd go with the option to disable the limit (--shm-size=0). Go for it, @masch!
Still, we'll have to wait for @debarshiray to make the final call.
Great! I'll do the PR and you give me feedback on it.
Interesting. I thought we had a /dev/shm just as big as the host's.
The history here is encoded in these two commits:
fdc00a2778afab061bf165429c4a3f3497dd091d: Back then, --shm-size didn't work with rootless. So we used --tmpfs to mount a tmpfs and calculated the size manually to mimic the kernel's defaults.
3e7400836ff6cdfc22bedde76ea21dd504b97463: Then we switched to --ipc hostto make Qt applications run without QT_X11_NO_MITSHM. I confess that I don't really understand exactly what that environment variable is supposed to do, so the fix was a bit of throwing random things at the wall and hoping something would stick. Using --ipc host did give us the host's /dev/shm - I am quite sure that it wasn't 64M.
So, I am wondering if something changed in Podman. Anyway, I don't mind explicitly using --shm-size if that's considered better.
I've created the #514 PR, let me know what do you thing.
Thanks @masch! LGTM!
I wonder if https://github.com/containers/podman/pull/7109 is relevant.
I played around with Podman 2.0.2, and Qt applications again don't work without QT_X11_NO_MITSHM.
If you compare ls -l /proc/self/ns/ipc both on the host and inside the container, you will see that the IPC namespaces are different. This is also what the new test case in https://github.com/containers/podman/pull/7109 asserts.
I'd rather we let this get fixed at the Podman level - we already have a fix, and, even better, tests to stop this from regressing again.
Note that this isn't just a matter of the size of /dev/shm, and, generally speaking, we are better off ensuring Podman stays stable and regression-free instead of trying to paper things over in Toolbox.
Thanks for noticing this, @martinpitt !
I think that we should have (more) tests in Toolbox that assert the various attributes of the containers. eg., in this case the IPC namespace.
Duplicate of https://github.com/containers/podman/issues/7100
@debarshiray : Interesting, thanks! I know that docker has always defaulted to a private separate 64 MB (by default) /dev/shm, and I just assumed that docker would do the same. So the idea is that with --ipc=host podman should just bind-mount the host's /dev/shm?
So the idea is that with --ipc=host podman should just bind-mount the
host's /dev/shm?
That's my understanding, yes. I think it also shares the semaphores and message queues between the host and the container, but I haven't actually tried them out.