setting 'ulimit -s' within /etc/system
jsmith665
by 'ulimit -s' (i.e., maximum size of stack segment) for Solaris 8/9?
The "Solaris Tunable Parameters Reference Manual" references both
'lwp_default_stksize' and 'rpcmod:svc_default_stksize'. From the
description, "Default value of size of stack to be used when a kernel
thread is created," the former would appear to be the desired
parameter.
However, testing with either and both (rebooting the system between
settings) appears to have no effect on the desired setting---'ulimit
-s' reports the default of 8192 regardless of the settings of the two
aforementioned parameters.
Any help would be appreciated.
Michael Tosch
ulimit -s is environment, automatically inherited by child processes.
Certainly you need it for certain processes only, and can set it
more close to these processes? E.g. in a /etc/rc?.d start script?
--
Michael Tosch @ hp : com
jsmith665
Agreed. The processes that require the change are incorporated into a
series of scripts (both startup and otherwise), all sourcing a
"setenv" script, which calls 'ulimit -s'. Should be end-of-story.
Unfortunately, the workstation in question is used exclusively as an
admin console for a specific application, and the vendor has convinced
the project manager that the 'ulimit -s' setting needs to be set
system wide. There are a number of ways that that might be done,
including setting it in the system profile as well as incorporating
into specific processes, as per your suggestion above. But, adding it
to /etc/system seemed the most comprehensive (not to mention the
easiest) way. Hence, my quest.
Casper H.S. Dik
Those two parameters are for kernel threads; and they are in bytes.
Please change them back because you may now be wasting tons of memory.
You are interested in the per-process stack; this cannot be set
system wide except through, e.g., /etc/profile or /etc/.login.
Users are free to change that limit in anyway.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
jsmith665
On 24 Mar 2006 10:55:08 GMT, Casper H.S. Dik <Caspe...@Sun.COM>
wrote:
>jsmith665 <jsmi...@hotmail.com> writes:
>
>>Is there an /etc/system parameter that is equivalent to the value set
>>by 'ulimit -s' (i.e., maximum size of stack segment) for Solaris 8/9?
>
>>The "Solaris Tunable Parameters Reference Manual" references both
>>'lwp_default_stksize' and 'rpcmod:svc_default_stksize'. From the
>>description, "Default value of size of stack to be used when a kernel
>>thread is created," the former would appear to be the desired
>>parameter.
>
>>However, testing with either and both (rebooting the system between
>>settings) appears to have no effect on the desired setting---'ulimit
>>-s' reports the default of 8192 regardless of the settings of the two
>>aforementioned parameters.
>
>Those two parameters are for kernel threads; and they are in bytes.
>
>Please change them back because you may now be wasting tons of memory.
>
>You are interested in the per-process stack; this cannot be set
>system wide except through, e.g., /etc/profile or /etc/.login.
>
>Users are free to change that limit in anyway.
>
>Casper
Thanks, for the definitive answer.
We did make note of the fact that both parameters set the kernel
thread stack size (one for normal threads, the other for rpc). But,
in the absence of information to the contrary, either seemed a
possible (if unreasonable) candidate. And, we did notice the spike in
memory utilization, as well. So, not having the desired effect, the
parameters have already been returned to their pre-testing values. We
will revert to our original plan, of adding the 'ulimit -s' command to
the process scripts requiring the change.
Thanks, again.
Casper H.S. Dik
>We did make note of the fact that both parameters set the kernel
>thread stack size (one for normal threads, the other for rpc). But,
>in the absence of information to the contrary, either seemed a
>possible (if unreasonable) candidate. And, we did notice the spike in
>memory utilization, as well. So, not having the desired effect, the
>parameters have already been returned to their pre-testing values. We
>will revert to our original plan, of adding the 'ulimit -s' command to
>the process scripts requiring the change.
Note that the tunables are all described in the docs.sun.com
Kernel Tunables guides.