Re: Unixware 2.1.2/Informix Online 7.23: Online won't boot: ulimit '-s': mystery error

jerry sutton wrote: > Cosmo Lee wrote: > > > > We're running Online 7.23 on Unixware 2.1.2 on a SuperMicro dual- 180MHz > > Pentuim Pro machine. > > > > We just upgraded from Unixware 2.1.1 to 2.1.2. Immediately we had a > > problem, Online would not boot. Double-checked all the kernel > > parameters in the release notes - everything fine. > > > > To make a long story short, the solution was to run `ulimit -s 8192`. > > This enabled Online to boot. But there are several mysteries that > > remain unsolved. > > > > 1) I didn't even know that the "-s" option existed. It sets stack size > > - (stack size of what? the shell, I guess?). > > > > 2) The "-s" option is not indicated in the ulimit man page, and there's > > no entry for it in the online docs. You have to go to the ksh93 man > > page to find info on the ulimit "-s" option. (Make it hard to find, why > > don't you SCO!) > > You are barking up the wrong tree here and exposing your own ignorance. > SCO is NOT responsible for the failure of shell builtins to be visible > at the man command level. As a bit of an aside, Sun is the only vendor > I know of ever to have documented the shell builtins in separate > manual pages ... and built a wrapper around source code control system > which I personally detest, but that's another issue. If you read the > plain ksh man page you will note that the underlying C language call > is not ulimit (though there is such a thing) but rather getrlimit() > and the matching setrlimit(); to my way of thinking these system calls > supercede the older ulimit(). SVR4 is FAR more complicated than earlier > releases in terms of providing control over this kind of thing. > re: ignorance That's just about the silliest response I've gotten from a news posting. Of course I'm exposing my own ignorance - I'm asking a non-rethorical question. Ignorance is a lack of knowledge. One seeks to remedy that lack by posting a query. I fail to see a point in your remark other than to snipe and demonstrate how obviously superior your knowledge is. Or perhaps you are exposing your own ignorance about what newsgroups are for? re: SCO I disagree with your opinion on SCO's responsibility. If they are to include a man page for `ulimit`, it makes no sense to document only a single option (-f) of many, and omit all the other ones as if they don't exist. This is surely misleading. How is one to even know that other options exist? Why should one have to look in multiple places to find all the options? Is one to assume for every command that somewhere, some place else, there are other options floating around which are not shown in the man entry? Then what's the point of having a *reference* manual? Either put all the options on the `ulimit` man page, or don't put them there at all ,and write "see options under ksh93". > > 3) So, the magic solution was to run `ulimit -s 8192`, then Online would > > boot. But what is strange about this is that the default on our system > > - when we run simply `ulimit -s` - is 16384 - twice 8192. > > > > Why would Online not boot with a stack limit set at 16384, but be OK > > with 8192? > > What happens every time a shell forks a new process? Among other things > it consumes ARG_MAX bytes for the environment. And it consumes space > for the stack. And a few other resources. > > How many processes does 'Online' want to start? If each new process > consumes XXX + 16384 bytes in the default case but XXX + 8192 bytes > after running ulimit, can you start more or fewer processes before > running out of memory when you use XXX + 8192 bytes for each new > process? You may be running dangerously close to disaster now ... > you may need more physical RAM. > This Online instance takes up 18MB of RAM. It is the only major application on this newly configured server, which has 128MB of RAM, so I doubt that this is the problem. > -- > Jerry Sutton jerrys@airmail.net > and of course, I don't speak on behalf of my employer -- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ADDRESS ALTERED TO FOIL SPAMMERS: Remove "*NO-SPAM*" to reply. Cosmo Lee Multi-User Computer Systems Brooklyn, NY "JUST SAY 'NO' TO SPAM" * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *