Thanks for your post Brian: It is hard to tell what process is throwing this error as it is only displayed as the PID and since the process dies and svc watcher attempts to restart it the PID number changes. >From /var/adm/messages around the time that this error is generated xorg is >also trying to start. So My best guess is that it is xorg that wants more >stack size.
Is there a way to increase the global max-stack-size above its default of 10Meg? /etc/project does not do this. I have found that /etc/project is not working properly even under Solaris10u5 & u6, I am working this through Sun support now. > > I'm guessing here, but: the limit probably comes from > the shell-imposed > stack limit (default 10Mb / 10240Kb). > This is normally put in place to catch bad apps or > recursive functions > that don't stop recursing. It helps stop one process > quickly consuming > vast amounts of RAM (OK, a simplistic approcach, I > know). > > The question is - what is the app, and why does it > need more than 10Mb > for stack? > If it really does need that much, then it may need to > have the stack > limit increased (perhaps a shell script wrapper with > the appropriate > "ulimit -s" command, or maybe there's a more clever > way to do this now > :-) ). > > One word of caution, especially for 32-bit processes: > Don't be too > liberal with the setting for the stack limit. Because > of the location of > stack and libraries within the process virtual > address space, the stack > limit effectively removes that amount of memory from > the process. In a > 32-bit process, only 4Gb is available, and setting > the stack limit to > 1Gb would actually only leave approx 3Gb for the > process to use (despite > the stack only being a few Kb in size). > > I would suggest looking at what the process is, and > see whether there is > a software fault there first, before fiddling with > the stack limit. > coreadm should help you catch what the process is (as > out of stack > generates SIGSEGV I believe) if you don't already > know. > > > Regards, > Brian > > -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
