Re: Any particular reason we don't have sshd oomprotected by default?

On Fri, Nov 10, 2023 at 10:31:53AM +0800, Philip Paeps wrote:
>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
>

Hi folks,

      This is a relatively common scenario, yes - but interestingly
      enough, FreeBSDs version has not only the @ invocation with a bunch
      of different values, it can do arbitrary time-lengths as specified
      with seconds.

      The best part about the @ invocation, though, is that it attempts
      waits that many seconds after the previous run has exited
      successfully - so it's much harder to get into a situation as
      described above.

      My only reason for mentioning this, is that I think it's a pretty
      neat little feature that not enough people know about, given its
      usefulness.

Yours,
Daniel Ebdrup Jensen

-----BEGIN PGP SIGNATURE-----

iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmVODDZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF
ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN
87pC7AgApFf9xs8dtfI7W5L6Sckw9APWgtG60+YAHCMD4IX1IXalJrhu4HrdRHZW
sU15uDzg5JowedMDhCz5peUl4UlRMNWGadRw6MKL03Rs7ijWNhb90OdOFmHF1/0j
9HVL6KSBWr8w6NptRrXQj793LEBMXuaE3FUTBiHhENcFBu7im80UP0S/iscw1gOY
D9YZ+cpKXXuIxmEfZYfVa6RwRHKYePz0vzC3O3GP6PvfMnd+kwEqlzd73YVlP+C+
blDKQaY91Ut4BuHQCFlJNijz3kE5YR7V3pz50RYJcYeLpUVq3Z5snD6GdXdQRxIE
u8Kn5et6I9K1EE++TyA8U8+zse3POw==
=dsLU
-----END PGP SIGNATURE-----