ulimit -v

I've noticed that /etc/security/limits.conf does not have an option to set the virtual memory limit for a user (ulimit -v), and I have been considering putting

"ulimit -v 5000" into the /etc/profile file, so that all users get limited to 5000 bytes of memory when running their programs.

However, I do not want this to apply to root, when he logs in.

Does anyone have any ideas about how I could do this?

I've tried putting:


into /etc/profile, where /bin/limitfile is a script that simply runs 'ulimit -v 5000',

unless the uid of the caller is < 100,

however that has not worked - am I doing it wrong or is there a reason for this?

Suggestions would be very much appreciated.

7 Replies

In my /etc/profile I already have an if block for root that looks like:

if [ `/usr/bin/whoami` = 'root' ]
    #do stuff special for root
    #do stuff only for !root

You should just be able to add "ulimit -v 5000" to the else section of the if block. A quick check of this works on my local workstation, I see no reason why it would fail for a linode. However, when setting ulimit in /etc/profile I believe the limit is per process not per user.

If it seems to be failing, try bumping up the value as a test, when I was playing locally a setting of 2000 would not even let me spawn a shell.

This is a bad idea. First it is possible for a user to not exec/source the /etc/profile file. Additionally, a user can use the fakeroot libraries to give other programs the appearance that they are the root user.

Bill Clinton

Ok then Bill Clinton, if that won't work, what would you suggest?


Mr. Clinton is completely correct, from your tone I thought it was a more informal limit of users not a heavy security measure, I should have mentioned that.

Here's a thought…. I know that linodes sometimes have issues when they're asked to do a lot of writing data to swap, due to bad swapping code (or has this been resolved?).

Anywhoo, if it hasn't, would it be a net performance gain to allow, instead of :


max locked memory


all being 5M

and virtual memory being 25M (I have 192M total avalible)…..

Maybe I should set normal memory up to 10M, and virtual mem down to say… 15M?

That would limit the ammount of virtual memory hungry processes were using, and thus, speed up my linode. Is this a good idea?

In general the best solution is simply keeping the regular active applications from swapping all together. If you find yourself constantly hitting swap for active applications you really need to add more ram or reduce your regularly running application load.

In my experience (non-linode) artificially limiting any program from using the memory it needs is a reciepe for disaster. Using memory restrictions to keep processes in check so they don't accidentally steal all of the resources is useful, but beyond that the better solutions include either adding more resources or re-engineering the application to run with less resources. Of course while some applications provide configuration level resource usage tweaking such as apache or mysql, most others are beyond the reasonable scope of change.

/sorry for replying to myself here, too different to edit and add to the previous post

I just checked your web link, I was thinking of a LAMP host not a shell provider when I wrote that, so it does not apply to your situation very well.

I don't have a lot of experience running as a shell provider without prior knowledge of exactly how they are going to be used to pre-plan memory limits. However, your reasoning of increasing the amount of available running memory and consequently lowering virtual memory seems very reasonable assuming that the average user regularly utilizes more than 5M (bonus points if it is also normally <10M).


Please enter an answer

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct