rss ulimit does not apply

Bug #701141 reported by timo skrempel
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

I am running Ubuntu 10.10.

Setting a resident memory limit via "ulimit -m" or limits.conf has no effect. Something similar was already reported in https://bugs.launchpad.net/ubuntu/+source/pam/+bug/71024
and marked as fixed.

Setting the virtual memory limit via -v works correctly, but limits.conf does not allow to set the virtual memory limit? Why?

I am testing with a c program that does an malloc() followed with a memset(). Instead of receiving an allocation error or the program getting killed, it can fill up the memory, the machine starts swapping, and becomes unusable.

Tags: kj-triage
Revision history for this message
timo skrempel (timoskrempel) wrote :

The limit is visible in "ulimit -a" though, but has no effect.

Revision history for this message
Steve Langasek (vorlon) wrote :

Please show the limit you are trying to set in limits.conf.

A failure to apply a ulimit -m in limits.conf is a separate bug than the lack of support for setting virtual memory limit in limits.conf. Which is the issue that you're trying to get resolved? If both, please file a separate bug report for the other issue.

Revision history for this message
timo skrempel (timoskrempel) wrote :

The setting from limits.conf _is_ applied. I added a line
"* hard rss 1000000"
to /etc/security/limits.conf. After a reboot "ulimit -m" correctly returns
1000000
The default before was "unlimited".

The bug is that this limit is not enforced. A program can allocate and use as much memory as it wants.

Revision history for this message
timo skrempel (timoskrempel) wrote :

C++ program that shows the bug. Set "ulimit -m 100000" and it has no effect. You can check the memory usage with top or ps.

Revision history for this message
Steve Langasek (vorlon) wrote :

ok, enforcement of ulimits is up to the kernel, not pam. Reassigning to the kernel package.

affects: pam (Ubuntu) → linux (Ubuntu)
tags: added: kj-triage
Revision history for this message
andrey_campbell (andreycampbell) wrote :

Any updates?

I can confirm this as well.

Interestingly, other limits work; for example "ulimit -v" is enforced though it's not that useful.

Will this get fixed? IMO, the rss limit is tremendously useful for killing processes that balloon out of control. VLC as of late will balloon out of control when playing many fake movies that can be found online. This is so important that I ended up writing my own Python script (running with SCHED_RR, priority 99) that will retrieve ballooning processes using "ps" and then proceed to kill them if their rss exceeds a certain amount.

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 701141

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
andrey_campbell (andreycampbell) wrote :

As far as I can tell, this is not something that would require any additional information.

This does not work for anyone - it's as simple as that - meaning that any information collected is just as good no matter from which computer it was collected.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
penalvch (penalvch) wrote :

timo skrempel, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.