profile: cannot fork: too many processes

[Bill Hassell]

Since the problem seems to be recurring, look at /etc/inittab to see if someone put a bad entry there. A respawn for this problem script may be causing all this mess. Change respawn to off, comment the entry or simply remove the entry. Or the problem may be in cron -- look at both root and scott cron entries. And finally, remove any bad profile code by renaming ~scott/.profile and ~scott/.kshrc to something else like .profile.old and .kshrc.old.

[someoneElse_1]

.profile and .kshrc is being shared with other user and that user is not having any issue.
cat /etc/passwd | grep scott
scott:*:20445:20244:Application Developers:/home/scott:/usr/bin/ksh

crontab has no entry for scott user

inittab content attached

[Alzhy]

Look at ~/scott/.ssh
If it exists, rename authorized_keys or authorized_keys2 file to something like *.org

Long shot..but scott's processes could be spawned via ssh?

[Dennis Handly]

>where to put -STOP in above code?
>is above code ok to run

You don't. You can run the above but you won't get anywhere with the fork bomb. My suggestions on Mel's scripts are to prevent useless output. But they don't solve anything.

You need to do these two steps. The first to stop the slippery PIDs and the second to kill them all. You could repeat the first several times.
kill -STOP $(UNIX95=EXTENDED_PS ps -u scott -opid=)
kill $(UNIX95=EXTENDED_PS ps -u scott -opid=)

>Bill: Since the problem seems to be recurring, look at /etc/inittab

A fork bomb recurs too.

>And finally, remove any bad profile code by renaming ~scott/.profile and ~scott/.kshrc to something else like .profile.old and .kshrc.old.

Yes, I was also thinking that but just changing the permissions to: ugo=
I.e. after we kill all of scott, the next login may start it again.

>.profile and .kshrc is being shared with other user and that user is not having any issue.

How is it shared, a copy?
Why not change the permissions and see if things stop?

>inittab content attached

I don't see it.

>Alzhy: scott's processes could be spawned via ssh?

>rename authorized_keys or authorized_keys2 file

Instead of rename, change the permissions: chmod u-rwx ~scott/.ssh

The following may tell you the login source:
who -a | grep scott

[someoneElse_1]

thanks I am able to login now

kill -STOP $(UNIX95=EXTENDED_PS ps -u scott -opid=)

I ran this 3 times
and all processes killed

now i can login with user scott


Dennis ThankYou very much for help.

This is very helpful

[Alzhy]

So what was causing the persistent runs of those ksh processes? Was there indeed an ssh session from elsewhere ?