Date: Fri, 10 Nov 2023 10:31:53 +0800 From: Philip Paeps <philip@freebsd.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Robert Clausecker <fuz@fuz.su>, Alexander Leidinger <Alexander@leidinger.net>, freebsd-arch@freebsd.org Subject: Re: Any particular reason we don't have sshd oomprotected by default? Message-ID: <281A373B-E3E2-480E-AE00-C8C691463106@freebsd.org> In-Reply-To: <20231109195959.7B33B348@slippy.cwsent.com> References: <8b9484ba83e373ece0e322e14c924da6@Leidinger.net> <ZUyTnDAJ3HOppG8h@fuz.su> <C31C649C-049E-487F-9ADB-C8B3A78C4020@freebsd.org> <20231109195959.7B33B348@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2023-11-10 03:59:59 (+0800), Cy Schubert wrote: > Philip Paeps writes: >> On 2023-11-09 16:09:00 (+0800), Robert Clausecker wrote: >>> I encountered the same issue a while ago, leaving my system in a >>> vegetative state. I would propose to add syslogd and cron to the >>> list. Syslogd because when it dies and you don't notice, you may go >>> for >>> a long time without syslogs, cron because a dead cron means no >>> housekeeping tasks happen, including some which the administrator >>> may >>> have intended to fix an issue causing an OOM condition (e.g. >>> periodically restarting services with known memory leaks or cleaning >>> tmpfs-based file systems). >> >> In my experience, cron is more often the cause of an OOM condition >> than >> a help to making it stop. :-) > > Would that be cron or something that cron has started? A common pathology is something that is started every few minutes in the expectation that it will take less than a few minutes to run. Instead, it runs away with all memory. I'd rather let cron die of starvation than have it make the situation worse. So yes: something that has started. cron itself is not eating all memory. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?281A373B-E3E2-480E-AE00-C8C691463106>