Please set memory limits by default

A plausible solution would to be enable pam_limits by default, and add support for setting virtual memory limits with a percentage.

In that vein, it would be also handy to be able to set the max number of processes based on the number of cores.

Not sure if this is being worked on, but I think this is a VERY important issue to fix!

Every once in a while, something I run has a massive memory leak (GB/s), which brings down the entire system, requiring a hard reboot.

this seems like FAR from ideal behavior!

while there are valid reasons for a program to use more than the available physical memory in the system, at least in my experience, if a program is trying to use more than the 2gigs of memory I have, its due to a bug, and I'd rather the process be killed, than the entire system!

Even better would be to prompt the user for whether they want to allow the process to continue...
ie: if a process is using >80-90% of physical memory, force it to go to sleep, and prompt the user for them to decide wether to allow the process to proceed.

Not sure how the prompt would work, other than a GUI popup, or shell message, both of which have their flaws though...

thanks!

A memory leak alone doesn't bring down a Linux system; the Linux kernel will kill off the process responsible if it sees that too much memory is being used.

So whatever problem you're having that requires a hard reboot is more than this.

How did you determine that the problem you're seeing is due to "something" having a memory leak? If you know there's a memory leak, surely you should know what process is leaking?

@Steve

I stand ready to be corrected, but my understanding is that Linux will only kill processes when it actually runs out of memory. This only happens when it runs out of swap. If a process is out of control, then it will cause the system to thrash the swap and become unusable, but long before Linux runs out of memory to allocate and invokes oom_kill because it can still allocate out of swap.

By this point everything you actually need has gone into swap, so there is a long delay before you can open a terminal window and find and kill the errant process. Less technical users would have to go through System->Administration->System Monitor->Processes->End Process and this would involve many more page faults on the GNOME library and take considerably longer. Even Ctrl-Alt-F1 takes a long time, let alone the time it takes to log in and run top.

We are talking many minutes of swap thrashing before the user can get things back under control. There is a limit to how long the system has slowed to a crawl so much as to be unusable before a user can claim that a hard reboot was the only option. If it takes tens of minutes, then a hard reboot is easier for the user to perform.

Setting a resource limit seems like a much better idea, doesn't it?

A memory leak at a rate of a GB/s would quickly exhaust all system memory and trigger the OOM killer. If the memory is being allocated in very small quantities then it may swap for a while, but the system will recover in due order.

Which is why, independent of whether we should be setting resource limits, I think "blah" has some other problem on his system than just a memory leak.

I believe the problem is when an application allocates memory in very small chunks. The OOM killer works well if you ask for 5GB and there is only 1GB in the system, but nothing prevents an app from taking up all available memory, forcing the system to grind to a halt and even if it might recover after several hours... once it crosses the limit. That's not enough because the system is dead in the mean time.

BTW, I've had this problem repeatedly in the past with evolution and file-roller.

Like Steve, I used to think that "the Linux kernel will kill off the process responsible if it sees that too much memory is being used". But just two days ago on our Jaunty server with lots of GB RAM and no swap, a number of system processes were killed during a long-running memory-consuming calculation, including dbus-daemon, syslogd, console-kit-daemon. Although the server happily responded to ping, I couldn't login neither through ssh nor at the console. In the end I was forced to perform a hard reset.

It looks to me like there is a difference in the behaviour between a) the system going out of memory and b) a process reaching its memory limit. In case a) - i.e. no limit - the process to be killed is selected according to some score.

Attached is a screenshot from the remote access console.

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

In Karmic, memory limits are still not set. ulimit -a reports data seg size, max memory size and virtual memory are all "unlimited".

I have the percentage based memory limits working fine. Currently, if the char suffixing the value in security.conf is a %, it will calculate the max virtual memory size based on the physical memory size. I'm tweaking it, and bug testing it at the moment.

Do any of the other memory limiting options (max locked memory, max memory size, stack size) need this percentage option as well?

The above fix I have written does what it is coded to, but does NOT create the required behaviour. If a user has a process that starts eating memory, then the entire session will be terminated, and the user will be booted back to the login screen.

Note that as of oneiric, pam_limits directly probes the kernel for default limits to set (by reading /proc/1/limits), and it is our stated policy that pam_limits should not impose any policy by default other than the one given by the kernel itself. As such, though a feature to allow specifying memory limits as a percentage in limits.conf may be useful:

 - this should be submitted upstream first rather than being applied as a patch in Ubuntu
 - the default limits.conf shipped in Ubuntu will not use this feature, even if present.

If your aim is to get limits applied by default, please submit a patch to the kernel instead. The kernel already sets several default limits based on available system resources, so there's no problem in principle with doing the same thing for memory limits (though the exact limit chosen will have to be justified to upstream).