ksh: cannot fork: too many processes

[Manuales]

what is the meaning of the following messsage ?

ksh: cannot fork: too many processes
i know that is related with a kernel parameter but i do not know which one is and what must be the new value ...

can you help me please ?

i mean:

it appears every time i run a script that only use the following commands into the file named serveruno.sh

- remsh (file into remote shell named hola.sh)
hola.sh contains:
- omnirpt command
and then (into the server where is showing the message continuew the script named server.sh working) continue the following commands:
- obtain a value that was captured as variable when remsh command was run(is the string of the file)
- send an email (email command)
ksh: cannot fork: too many processes

thanks, Manuales.

[Pete Randall]

This message means that the number of processes currently running has exceeded the kernel value nproc. You could try raising nproc and building a new kernel.


Pete

[Manuales]

Thanks Pete, but what is the new value than i have to put there in that parameter?

[Pete Randall]

Actually, come to think of it, it could be maxuprc, too.


Pete

[Patrick Wallek · Accepted solution]

It could be one of 2 parameters: maxuprc or nproc.

maxuprc = The maximum number of processes each user can start.

nproc = The maximum number of system wide processes.

Check both parameters and see what their current values are.

ps -ef | wc -l

Will give a close count of the total number of processes on the system.

ps -ef | grep root | wc -l

will give you a count of the number of processes the root user, assuming that is who you are logged in as, is running. If you are logged in as a different user, substitute that id for root in the above statement.

[Patrick Wallek]

Only you can answer the new value question.

Depending on your settings you might want to increase the appropriate parameter by 50% or perhaps 100%.

Note that depending on the version of HP-UX you are running, this could require a reboot.

If I recall correctly, maxuprc is dynamic at 11.11 and later, but requires a reboot for 11.0 and earlier.

I believe nproc still requires a kernel recompile and a reboot for all versions.

[Pete Randall]

Increasing both of these values cost you little but a tiny bit of extra memory. I would double them and see what happens.


Pete

[spex]

Hi Manuales,

Check your scripts for unintentional looping.

maxuprc:
maximum number of processes per user
nproc: maximum number of processes system-wide

Under 11i, the default value of maxuprc is 1000, and nproc is (20+8*MAXUSERS), or 2020. maxuprc is dynamically tunable, while nproc is not.

PCS

[Manuales]

This is the result:

$ ps -fea | wc -l
336
$ ps -fea | grep root | wc -l
138 -l

maxuprc: 2048
nproc: 3220

then, do i have to replace the id that i am using by root?

Manuales.

[Sandman!]

Check your /var/adm/syslog/syslog.log file for related error messages. It will point you to the corresponding kernel parameter that needs to be changed in order to alleviate this problem. If the syslog doesn't have an entry then it's related to maxuprc.

~hope it helps

[Patrick Wallek]

Yes. If you are not logged in as root, then substitute that id for root in the 'grep' statement.

I thought I said that before.......

[Sandman!]

Adding to my last post: nproc limit exceeded will be logged to the syslog.log file but not if the limit on maxuprc is exceeded. Look in /var/adm/syslog/syslog.log file to figure out whether it's nproc or maxuprc.

~hope it helps

[Bill Hassell]

Actually, grep is seldom accurate when used with ps. Use ps as your only tool:

remsh someserver "ps -ef -u user1 | wc -l"

Also check how close the current process count is to your nproc value:

remsh someserver "sar -v 1 1 | tail -1 | awk '{print \$4}'"

It will return numbers like 356/4033 which means 356 processes running with room for a total of 4033. If you see numbers like 3999/4033 then yes, you need to DOUBLE or TRIPLE the kernel parameter NPROC. Just increasing it a little bit means you'll probably have to change it again (requires a reboot) as your system gets busier.

So you first must test your remote command that it properly works. But most important: remsh (and rexec) do NOT have a login environment. The only variables set are:

LANG
PATH
LOGNAME
SHELL
HOME
PWD
TZ

Your remote script must setup all additional variables required for proper operation. You can also trace your remote script by inserting set -x at the top.

[Jonathan Fife]

Hi Bill,

I'm just curious about this statement:
"grep is seldom accurate when used with ps. "

Can you clarify that? What should I be wary of when I use ps -ef | grep?

Thanks!

[Peter Nikitka]

Hi Jonathan,

look at the answers of me, Bill and James in the thread
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1067697

mfG Peter

[Bill Hassell]

grep matches anything on the line with the string you want. Suppose you want to find PID 123 and all processes owned by bill and all processes named "sh":

ps -ef | grep 123
(matches PID 123 1234 2123 etc)
(also matches PPID 123 1234 3123 etc)

use: ps -f -p 123

ps -ef | grep bill
(matches bill billh waybill billg etc)

use: ps -f -u bill

ps -ef | grep sh
(matches sh ksh csh bash unhasdaemon etc)

use: UNIX95= ps -f -C sh

grep is working exactly like it is supposed to but you can't tell grep to look at a certain column.

man ps has a lot of details. See especially:

-u
-p
-x
and with UNIX95=
-C
-H
-o