ulimit stack size smaller on hpux11i?

[Stuart Abramson_2]

1. ulimits are different on acshps05 and wcshps06:

saroot@acshps05:/home/saroot# ulimit -a

time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 341796
stack(kbytes) 12288
memory(kbytes) unlimited
coredump(blocks) 4194303

saroot@wcshps06:/home/saroot# ulimit -a

time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 341796
stack(kbytes) 8192 <== stack smaller
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 60 <== maxfiles smaller

2. But the kernel parameter that controls stack size (maxssiz) is
the same:

saroot@acshps05:/home/saroot# kmtune -lq maxssiz

Parameter: maxssiz
Value: 12582912
Default: 0x00800000
Minimum: -
Module: -

saroot@wcshps06:/stand# kmtune -lq maxssiz

Parameter: maxssiz
Current: 12582912
Planned: 12582912
Default: 0x00800000
Minimum: -
Module: -
Version: -
Dynamic: No


Is the ulimit SMALLER on hpux 11i? Why would that be?

[Pete Randall]

Stuart,

Interesting. Mine are the same:

manitoba(268)root# uname -a
HP-UX manitoba B.11.11 U 9000/800 165901597 unlimited-user license
manitoba(269)root# ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 262144
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 60

yukon(63)root# uname -a
HP-UX yukon B.11.00 U 9000/800 650349313 unlimited-user license
yukon(64)root# ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 966852
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 60


Pete

[A. Clay Stephenson]

My stacksize as reported by ulimit exactly matches the value specified by maxssiz in 11.11 and 11.0. My best guess is that you have a smaller ulimit set in /etc/profile or .profile.

[Steven E. Protter]

11.11

[141]# ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 2015464
stack(kbytes) 131072
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 4096


[142]# kmtune -lq maxssiz
Parameter: maxssiz
Current: 134217728
Planned: 134217728
Default: 0x00800000
Minimum: -
Module: -
Version: -
Dynamic: No


11.00 (Still got one)
[1090]# ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 391272
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 180

kmtune -lq maxssiz

[1092]# kmtune -lq maxssiz
Parameter: maxssiz
Value: 0x00800000
Default: 0x00800000
Minimum: -
Module: -


My variances are due to decisions I made. I built the 11.11 system, not the 11.00 system, but I've managed it long enough to take responsibility.

I'm with A. Clay's conclusion.

Pete: Nice system names. I like cities. Mine come from Israel.

SEP

[Pete Randall]

SEP,

I almost edited them out but thought: why?

They date back to our very first servers when we started downsizing off the mainframe. HP came in to setup the orginal servers and arbitrarily named them after Canadian provinces. I keep saying that some day I'll go back to our original development and production names Sire and Dam, but I never get around to it. Knowing my sloppy, lazy programmers, I'd be fixing scripts for the rest of my life.

;^)


Pete

[Stuart Abramson_2]

I don't have any "ulimit" entries in /etc/profile or .profile. It happens to all users, not just to me. It happens to root.

On my hpux 11.0 systems, the ulimit values take on the kernel parameter values. On hpux 11i, all of the ulimit parameters take on the kernel parameter values, except maxssiz, which is smaller than the kernel parameter....

[A. Clay Stephenson]

I can't reproduce your situation but I do note that your ulimit -s value on your 11.11 box is the default maxssiz value. I'm beginning to suspect that you have something like a /stand/vmunix which does not match /dev/kmem. Such a situation can occur when a kernel has been built but not booted.

Try this as root because super-user is allowed to increase a ulimit value.

ulimit -s 12288
ulimit -a

If the value increased then ulimit has to be getting set somewhere but if you are not allowed to increase to that value then you are hitting the hard limit imposed by the maxssiz value.

[James Murtagh]

Hi Stuart,

If you're not hitting the hard limit as per Clay's comments you could be experiencing something similar to what was witnessed in this post :

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xc103dfdc95b632488ccd1ac6de561f9a,00.html

It was found that the 64 bit kernel limits take precendence over 32 bit limits as when the kernel forks init its a 64 bit process - all processes running on the system are decendants of init hence during the fork process the limits are inherited from it. To cut a long story short check maxssiz_64bit - its default from /usr/conf/master.d/core-hpux is indeed 8MB.

cheers,

James.

[Stuart Abramson_2]

I like both these last two answers:

1. I CAN increase my ulimit as root, but nobody else can.

2. I can't find anybody who is calling "ulimit" or /var/adm/cron/.proto . I have been doing "find"-s all day.

3. I think that my system may be getting mixed up with the 64-bit ulimit. I'm going to follow that other thread.

[Stuart Abramson_2]

James Murtaugh had the right answer.

For some reason, maxssiz was taking the smaller of the two:

maxssiz 12482912
maxssiz_64bit 0x00800000

It was taking maxssiz_64bit, which is 8 MB or so instead of the maxssiz which is 12 MB.

I bumped maxssiz_64bit up to equal to maxssiz, and now I'm fine.

James, send me something and I'll give you 5 more points.

Thanks, all.