topic Re: Ulimit setting problem in Operating System - HP-UX

Ulimit setting problem

Sakthimurugan.S — Thu, 15 Jul 2010 18:39:13 GMT

$ uname -a
HP-UX maa2tamh B.11.31 U ia64 0909076740 unlimited-user license
$ ulimit -aH
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 1048576
stack(kbytes) 131072
memory(kbytes) unlimited
coredump(blocks) unlimited
nofiles(descriptors) 4096

DBA asked to set the ulimit size to unlimited for stacks and data, but i am unable to set , got the below error, please advise how to set ulimit as unlimted for a particular user.

$ ulimit -s unlimited
sh: ulimit: The specified value exceeds the user's allowable limit.

Re: Ulimit setting problem

Steven E. Protter — Thu, 15 Jul 2010 18:58:13 GMT

Shalom,

root should be able to do this.

oracle user can not.

You may need to set this for root and then modify the oracle user profile to set this for the user.

Otherwise go for a REALLY big number.

SEP

Re: Ulimit setting problem

Sakthimurugan.S — Thu, 15 Jul 2010 19:11:14 GMT

Yes already i tried this able to set as root, but its not reflecting in user side, itf the users put ulimit -a , still its hows the old value, but if i try to increase the value, i got this error.
sh: ulimit: The specified number is not valid for this command.

Re: Ulimit setting problem

Don Morris_1 — Thu, 15 Jul 2010 20:09:21 GMT

man 5 privileges [the user in question must have PRIV_LIMIT to raise limits above the current hard limit].

In practice, though -- you would be better served raising maxdsiz/maxdsiz_64bit and telling the DBA unlimited stacks are a complete fantasy they aren't going to get. Regardless of what the rlimit claims -- the stack is still always going to be maxssiz/maxssiz_64bit bytes (rounded down to a unit of `getconf _SC_PAGE_SIZE` since the system only really works by pages) away from the end of the process private address space. Hence, it doesn't matter what your limit claims -- when you hit the end of the address space, that's it.

The data limit is still enforced as maxdsiz/maxdsiz_64bit (the value at the time of process creation if the unlimited setting was already in effect, the current limit if the ulimit (setrlimit(2) really) change was made after the process was already running. Granted, that doesn't really have to be that way as the stack layout does. And also, of course -- there's no guarantee you won't hit other private objects like mmap well before that.

So in short -- you may want to just raise your maxdsiz tunable (although unless the binary is using one of the non-default address space layouts, the private data space is 1Gb by default for 32-bit -- so it won't mean anything, you'll really get (1Gb - maxssiz) for your private objects which is data+private mmap + thread stacks, etc....) and explain to your DBA that raising the stack limit means lowering the space for data so they can decide if they really need it.

If they don't really need unlimited but just want it to feel good or satisfy an install script -- then by all means give them the privilege and let them set it.