3 ms·
> the container will OOM right away that doesn't really makes sense in linux-parlance. you should try and see which is the process that is actually triggering
by znpy 6y ago
> the container will OOM right away
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.
- znpy 6y agohere it is! https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html https://www.muppetlabs.com/~breadbox/software/tiny/teensy.ht... i was off by a bit. the binary is 45 bytes and prints the number "42" (plus a newline).
- nathell 6y agoIt does not print anything. It returns with exit code 42.
- jeffbee 6y agoI see that you haven't tried it. Note: read for comprehension. A container may OOM from kernel memory alone.
- umanwizard 6y agoWhat process or processes were you running in the container? Edit: nvm, saw you answered it in another thread: `find / > /dev/null`. Interesting!
- jeffbee 6y agoYes, 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.