A daemon calling abort() in response to malloc failure is like depositing all your money in response to capital controls.
@laurentbercot For a daemon? Good luck getting s6-supervise to successfully fork & exec a new one under OOM conditions...
-
-
@laurentbercot This issue actually came up in practice on the maradns list a few years ago. Whole dns goes down if one request OOMs. -
@RichFelker It's obviously better to specifically handle ENOMEM when you have a huge state that's costly to lose, such as a DNS cache. -
@laurentbercot You lose not just the cache, but the ability to serve future requests. That's the point of my "depositing your cash" analogy. -
@RichFelker Not if your daemon is supervised: it will come back up when the crisis is over. You can't serve while there's no mem anyway. -
@laurentbercot Sure you can. Serving cached or authoritative results takes no memory. -
@RichFelker Not arguing that maradns did the right thing. It didn't. (dnscache and tinydns don't have that problem; they're better designed) -
@RichFelker Just that in some cases (NOT a DNS cache), it's just as well for your daemon to exit on oom, and be restarted when possible.
End of conversation
New conversation -
-
-
@RichFelker Between that and being unable to serve clients anyway, there's not much difference. The exception is when you have in-mem state. -
@RichFelker Of course, OOM is a horrible event anyway, which should be prevented instead of cured, by smart resource limits management. 1/2 -
@RichFelker Unix is bad at this - there's no global resource controller. That could be the value of an integrated management system. 2/2
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.