Red Hat Bugzilla – Bug 249569
'ulimit -H -v' does not limit virtual set size
Last modified: 2007-11-30 17:12:11 EST
+++ This bug was initially created as a clone of Bug #249565 +++
+++ This bug was initially created as a clone of Bug #220657 +++
Escalated to Bugzilla from IssueTracker
-- Additional comment from email@example.com on 2007-04-23 06:47 EST --
*** Bug 237210 has been marked as a duplicate of this bug. ***
-- Additional comment from firstname.lastname@example.org on 2007-05-09 04:29 EST --
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
-- Additional comment from email@example.com on 2007-05-15 05:42 EST --
*** Bug 237212 has been marked as a duplicate of this bug. ***
-- Additional comment from firstname.lastname@example.org on 2007-06-14 13:00 EST --
Closing per Eric's comments on 6/14/ phone call.
Internal Status set to 'Resolved'
Status set to: Closed by Client
Resolution set to: 'RHEL 4.6'
Ticket type set to: 'Problem'
This event sent from IssueTracker by cww
-- Additional comment from email@example.com on 2007-07-11 10:24 EST --
*** Bug 247787 has been marked as a duplicate of this bug. ***
-- Additional comment from firstname.lastname@example.org on 2007-07-20 12:20 EST --
This problem also effects RHEL5, and Fedora 7. See bug #249051 for more
Interesting enough, ulimit -v does work for zsh.
[tim@cyberelk ~]$ rpm -q bash
[tim@cyberelk ~]$ ulimit -v 1
[tim@cyberelk ~]$ ls
Hmmm. You are right, ulimit -v works. It is only when you try to make it a
hard limit it fails to work:
(ulimit -H -v 1;ls)
In general, it looks like the it is the relationship between hard and soft
limits that is broken. For example, in theory the following should be legal
because 1 is less than 20000:
(ulimit -H -v 20000; ulimit -S -v 1 ; ls )
But instead the following error is returned:
bash: ulimit: virtual memory: cannot modify limit: Invalid argument
I am lowering the priority, since in most cases the -H flag is not necessary.
My understanding is that 'ulimit -H -v 20000' is expected to fail when the soft
limit remains at 'unlimited'. Move the soft limit first (-S), then the hard
limit (-H); or else move both at once (just -v on its own).
From a usability standpoint, it doesn't make sense to work that way. But, that
is the way it is designed...