On Fri, 29 Sep 2006 [EMAIL PROTECTED] wrote:
>
>
> >No - it must have changed because of an applied patch. Perhaps 118855-15
>
>
> No; it *must* be something you did.
>
> Nothing ever set the limit to 1000 for both.
>
> This persists across reboots.
>
> >> Pool resource controls?
> >>
> >> .files?
> >
> >BTW Casper - can you update this item on the Solaris FAQ please.
>
>
> About resource controls, you mean?
>
> These settings should still work.
more below...
> Please try "plimit" on all processes and see if a pattern emerges.
It appears that I've hit some bugs related to this. On "Machine A"
running Update 2 with kernel patch 118855-15, with no /etc/project files
anywhere on the system, when I login (/usr/bin/ksh set for shell) I see:
plimit $$
14377: -ksh
resource current maximum
time(seconds) unlimited unlimited
file(blocks) unlimited unlimited
data(kbytes) unlimited unlimited
stack(kbytes) 10240 unlimited
coredump(blocks) unlimited unlimited
nofiles(descriptors) 1000 1000
vmemory(kbytes) unlimited unlimited
So this is where my 1000 value is coming from.
On the same machine I logged into a zone (junkzone) and did:
projadd -U atg user.atg
projmod -a -K "process.max-file-descriptor=(priv,8192,deny)" user.atg
and when I ssh in as user atg I get:
21960: -ksh
resource current maximum
time(seconds) unlimited unlimited
file(blocks) unlimited unlimited
data(kbytes) unlimited unlimited
stack(kbytes) 10240 unlimited
coredump(blocks) unlimited unlimited
nofiles(descriptors) 1000 1000
vmemory(kbytes) unlimited unlimited
$
despite:
$ cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
user.atg:100::atg::process.max-file-descriptor=(priv,8192,deny)
$ id -p
uid=520(atg) gid=206(atg) projid=100(user.atg)
On the same machine, in the global zone, performing the same projadd and
projmod gives the expected behavior:
$ id -p
uid=520(atg) gid=206(atg) projid=100(user.atg)
$ plimit $$
26814: -ksh
resource current maximum
time(seconds) unlimited unlimited
file(blocks) unlimited unlimited
data(kbytes) unlimited unlimited
stack(kbytes) 10240 unlimited
coredump(blocks) unlimited unlimited
nofiles(descriptors) 8192 8192
vmemory(kbytes) unlimited unlimited
> (And check /etc/project)
>
> Casper
>
But wait - things get even stranger on another machine running Update 2
with only a couple of patches applied - mainly 118855-19.
In the global zone I have (/etc/system):
set ncsize=420000
set ufs_ninode=420000
set maxpgio=5000
set rlim_fd_max=65536
set rlim_fd_cur=12000
bash-3.00$ plimit $$
1134: bash
resource current maximum
time(seconds) unlimited unlimited
file(blocks) unlimited unlimited
data(kbytes) unlimited unlimited
stack(kbytes) 10240 unlimited
coredump(blocks) unlimited unlimited
nofiles(descriptors) 1000 1000
vmemory(kbytes) unlimited unlimited
bash-3.00$ cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
bash-3.00$
---
There are 2 "fat" zones, test1zone and test2zone. When I login as user
"al" (shell=/usr/bin/ksh) I get nofiles = 1000,1000 in both zones. Next I
modify test1zone and add the following to /etc/project:
atgproject:100::atg::process.max-file-descriptor=(priv,8192,deny)
user.atg:101::atg::process.max-file-descriptor=(priv,8192,deny)
Now when I login as user "al" to test1zone I still see nofiles =
1000,1000. But when I login to test2zone as use "al" I see:
$ plimit $$
2814: -ksh
resource current maximum
time(seconds) unlimited unlimited
file(blocks) unlimited unlimited
data(kbytes) unlimited unlimited
stack(kbytes) 10240 unlimited
coredump(blocks) unlimited unlimited
nofiles(descriptors) 12000 65536
vmemory(kbytes) unlimited unlimited
$
So adding /etc/project entries in test1zone affected my nofiles behavior
in test2zone!??
Conclusion: Neither machine behaves as expected. The different behavior
between the machines can be explained by the installed patches. Perhaps
several tests need to be added to ensure rational and consistant behavior
before a patch is released.
On the production machine, as a workaround, I can add a prctl command to
the startup script to set process.max-file-descriptor for the Java process
that is causing us problems.
Thanks for your help,
Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED]
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
OpenSolaris Governing Board (OGB) Member - Feb 2006
_______________________________________________
zones-discuss mailing list
[email protected]
