Is it normal that a user can take down the whole system by using too much memory?

[Brennan Vincent]

Thanks John for the response -- this should help me solve my practical needs.

I'm also curious, however, to learn more from an OS design perspective. Why isn't it possible for the kernel to realize it should kill `eatmem` rather than make the system unusable?

Is this a hard problem in general, or just a missing feature in FreeBSD specifically ?

On Sat, Jun 2, 2018, at 6:40 PM, John Howie wrote:
> Hi Brennan,
> 
> Do ‘man -k limit’ for details of means to restrict resource consumption. 
> In particular, check out limits(1) and rctl(8).
> 
> Variations of this problem have been around forever. An oldie but goldie is:
> 
> main () { while (1) { fork (); } }
> 
> I cannot say why you are getting the results you see on your specific 
> system. I would check limits to see where they are set, and tweak them.
> 
> Cheers,
> 
> John
> 
> 
> 
> 
> Sent from my iPhone
> 
> > On Jun 2, 2018, at 15:20, Brennan Vincent <brennan at umanwizard.com> wrote:
> > 
> > The attached program `eatmem.c` is a simple example to waste N gigs of memory as quickly as possible.
> > 
> > When I run something like `eatmem 32` (on a system with less than 32GB of RAM), about half the time everything works fine: the system quickly runs out of RAM and swap, the kernel kills `eatmem`, and everything recovers. However, the other half of the time, the system becomes completely unusable: my ssh session is killed, important processes like `init` and `getty` are killed, and it's impossible to even log into the system (the local terminal is unresponsive, and I can't ssh in because sshd is killed immediately whenever it tries to run). The only way to recover is by rebooting.
> > 
> > Is this expected behavior?
> > 
> > My system details are as follows:
> > FreeBSD 12 CURRENT x86_64 guest on VMWare Fusion.
> > ram: 8 GB
> > swap: 1 GB
> > Host: macbook pro running macOS.
> > <eatmem.c>
> > _______________________________________________
> > freebsd-questions at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"