I wonder how well it works. If you take an x86_64 system and make a memory control group with only 32MB of memory (and kmem tracking is enabled, which is true by default) the container will OOM right away. I've been operating under the belief that Linux now requires 64MB at a minimum, but perhaps a 32-bit uniprocessor build can get by with less.
that doesn't really makes sense in linux-parlance. you should try and see which is the process that is actually triggering the OOM.
if you're able to do that then you can try and swap that with another binary.
you could try and build an hello world that does while(1) sleep(30); build that with static linking and boot the container with that -- it will probably work.
also, i should look for that page, but i remember reading a page about trimming away anything possible from an hello world binary and ending up with something as small as like ~60 bytes.
Yes, find and its parent, the shell, but that's not why it OOMs. It OOMs because Linux uses a lot of memory for inodes and dirents and whatever it puts in slabs and then when memory pressure occurs -- when Linux must allocate in the kernel but cannot, due to limits -- it just loses its mind and instead of reclaiming it kills.
"should"... Unfortunately, almost everything is bloated these days. My first Linux box, a 386SX/20, had only 4 megabytes of memory. I ran SLS Linux which installed off of roughly 20 floppies. I could compile C programs, and barely run X!
