On Thursday, July 9, 2020 8:17:50 AM MST you wrote: > keep private mail private idiot You're responding to my post on a mailing list. I don't see any reason to keep this private. I'm not the only one on this list that you've attempted to contact directly with this sort of comment either, and I believe it's important that others are aware. > Am 09.07.20 um 17:09 schrieb John M. Harris Jr: > > On Thursday, July 9, 2020 7:57:25 AM MST Reindl Harald (privat) wrote: > >> my co-developer had a recursion in his code and after a few seconds the > >> machine was completly unresponsible due debugging the root cause > > > > That doesn't sound like anything to do with recursion > > stop telling people what things sound like when they know the truth It's true that I don't know your code, was just a guess. > > but either a memory > > leak, or unchecked allocation. It may help to limit the amount of memory > > that specific program can use, in order to help debug the issue. > > endless recursion of program code allocates endless memory, it's that > easy and it does it pretty quick Endless recursion will normally cause a stack overflow fairly quickly, and it doesn't necessarily allocate a lot more memory. I don't know what language you're using, but the only way that'd actually be "infinite" would be if it were fork()ing or exec*()ing another process. See below for my suggestions on protecting that, if you're interested. > >> even power-key took *15 minutes* for a clean shutdown while he was > >> tempted to hard power off the machine which is not much fun witch 32 GB > >> RAM and all sort of database services > > > > Yeah, OOM situations are never fun. However, with all sorts of database > > services, you wouldn't want something killing processes all willy nilly. > > that's why database services have OOMScoreAdjust=-1000 kid - they are > not killed willy nilly That'd be the case only if they're running as systemd units, not if they're spawned as a user process. For example, MySQL is spawned by Akonadi as the backend of KMail (and other KDE software). This wouldn't have an oom_score_adj set. > >> guess what was the solution: kill the fucking httpd worker before it > >> kills the system > > > > You can limit the process with cgroups, so that only the software you > > actually intend to limit is affected, and the rest works as you'd expect > > jesus christ you don't know *before* it happens what drives crazy and > putting arbitary limits everywhere does more harm If you're working on something that may "run out of control", you can apply cgroups yourself, to that process tree. You can always remove the limits when you're done working on it. The exact argument you've made against arbitrary limits is my argument against EarlyOOM. I hope that helps you understand where I'm coming from. -- John M. Harris, Jr. Splentity _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
