Process spawn multiple process

[A. Clay Stephenson]

A zombie process cannot spawn another process because a zombie process is not doing anything; a process could spawn another process and then become a zombie. It's impossible to kill a zombie process because the process is not running. Zombies comsume no resources and do no harm with one exception. A zombie occupies a slot in the kernel's process table; only in the case that you have so many zombies that that number begins to approach nproc is there any problem.

[Thiyagarajan.s]

Thanks for response

will take scenario

while
do
While < infinite>
do
&
done
done
a) above parent runs and creates infinite process which is sleeping ( may be zombie )
b) parent got killed becaues of some reason and many of the process has ppid 1
c) there is recursive process creation because of some reason

Can we come out of the above with out reboot

Please suggest if above is not clear

[Dennis Handly]

>Can we conclude zombie process can only killed by reboot

You kill zombies by killing their evil parent. Of course you have to decide if the parent is worth more than cleaning up the process table.

>parent got killed because of some reason and many of the process has ppid 1

Then these zombies should be killed when their parent is reset to init.

[Thiyagarajan.s]

If suppose user is allowed to run a script
he can run some script which create potentially zombie background process and at the end make the system down

So UNIX can be made down by a normal user

I feel i am not making any sense above

Please let me know if false

[James R. Ferguson]

Hi:

> ...suppose user is allowed to run a script
he can run some script which create potentially zombie background process and at the end make the system down...So UNIX can be made down by a normal user...

The kernel imposes limits on a variety of resources. These limits are "fences" to prevent one process or one user from consuming an entire resource (memory, open files, etc.)

In the case of processes, the kernel 'maxuprc' parameter limits the maximum number of concurrent user processes per user while the 'nproc' parameter controls the overal, system-wide ceiling.

While 'maxuprc' doesn't limit 'root', one doesn't let the "normal" user run as root anyway!

Regards!

...JRF...

[A. Clay Stephenson]

You really need to leave zombies out of your question. They are a by-product of but not the cause of your problem. Any process that can spawn multiple other processes either by intent or accident, can bring the system to a crawl. It's very easy to do with mutally recursive shell scripts or a shell script which simply calls itself. Of course, shell scripts are the trivial example but it could be Perl, awk, or binary executables. You can protect the system to some degree by setting maxuprc which will limit the number of processes which can be run by a user.

The real fix to your problem is educating your users and developers.

[Thiyagarajan.s]

James

normal user was not allowed , but accidentaly the process run by the user has ppid as 1

I always felt admin has control all thing if not i dont have words to say that even superdome can be - by single user

[James R. Ferguson]

Hi (again):

> normal user was not allowed , but accidentaly the process run by the user has ppid as 1

The fact that a process has a parental pid (ppid) of one (1) simply means that that process is now owned by 'init'. This will be the case seen when the parent of a process dies but its child remains alive --- 'init' inherits the child.

Regards!

...JRF...

[Dennis Handly]

>If suppose user is allowed to run a script
he can run some script which create potentially zombie background process and at the end make the system down

In general scripts can't create zombies, shells should prevent this. Only applications can. I'm not sure if perl gives the user enough rope to hang himself