How can I avoid zombies in Perl CGI scripts running under Apache 1.3?

Various Perl scripts (server-specific) invoke the Perl module with many features on the website. EDIT: Scripts use use lib to reference libraries from a folder. During busy periods, scripts (not libraries) become zombies and overload the server.

In the server list:

319 ? Z 0:00 [scriptname1.pl] <defunct> 320 ? Z 0:00 [scriptname2.pl] <defunct> 321 ? Z 0:00 [scriptname3.pl] <defunct> 

I have hundreds of copies of each.

EDIT: We do not use fork, system or exec, except for the SSI directive

 <!--#exec cgi="/cgi-bin/scriptname.pl"--> 

As far as I know, in this case httpd itself will be the owner of the process. MaxRequestPerChild is set to 0, which should not allow parents to die until the child process completes.

Until now, we believed that temporarily suspending some scenarios helps the server cope with non-existent processes and prevent it from crashing, but zombie processes are still forming without a doubt. Apparently, gbacon seems to be closest to the truth with its theory that the server cannot handle the load.

What can cause httpd to abandon these processes? Is there any best practice to prevent them?

thanks

Answer: It’s going to Rob. According to him, CGI scripts that generate SSI will not process these SSIs. SSI evaluation occurs before CGI runs in the Apache 1.3 request loop. This has been fixed with Apache 2.0 and later, so that CGI can generate SSI commands.

Since we were running Apache 1.3, for each page view, the SSI turned into non-existent processes. Although the server tried to clean them, it was too busy with working tasks to succeed. As a result, the server crashed and became unresponsive. As a short-term solution, we looked at all the SSIs and moved some processes to the client side to free up server resources and allow time for cleaning. Later we upgraded to Apache 2.2.

+7
perl apache zombie-process
source share
3 answers

I just saw your comment that you are using Apache 1.3 and which may be related to your problem.

SSI can run CGI. But the CGI scripts that generate the SSI will not handle these SSIs. SSI evaluation occurs before CGI runs in the Apache 1.3 request loop. This has been fixed with Apache 2.0 and later, so that CGI can generate SSI commands.

As I said above, try running the scripts yourself and look at the result. Do they generate SSI?

Edit: Have you tried running the trivial Perl CGI script to just print an HTTP response like Hello World?

Then, if that works, add trivial SSI directives such as

 <!--#printenv --> 

and see what happens.

Edit 2: Just realized what was going on. Zombies arise when a child process exits and does not receive. These processes hang around and slowly use resources in the process table. A process without a parent is an orphaned process.

Are you rolling back processes in your Perl script? If so, have you added waitpid () to the parent?

Did you also get the correct output in the script?

 CORE::exit(0); 
+2
source share

More Band-Aid than Best Practices, But Sometimes You Can Go Simple

 $SIG{CHLD} = "IGNORE"; 

According to perlipc documentation

On most Unix platforms, the CHLD signal (sometimes also known as CLD ) has a special behavior with respect to the value of 'IGNORE' . Setting $SIG{CHLD} to 'IGNORE' on such a platform has the effect of not creating zombie processes when the parent process does not wait() on its child processes (that is, the child processes are automatically retrieved). The wait() call with $SIG{CHLD} set to 'IGNORE' usually returns -1 on such platforms.

If you care about the exit statuses of the child processes, you need to collect them (usually called "reap") by calling wait or waitpid . Despite the creepy name, the zombie is just a child process that came out, but whose status has not yet received.

If your Perl programs themselves are child processes that become zombies, this means that their parents (those who are looking for and forget your code) should clean up after themselves. The process cannot stop turning into zombies.

+7
source share

Since you have all the bits yourself, I suggest running separate scripts on one of the command lines to see if you can detect those that are hanging.

Listing ps showing an excessive number of instances of one particular script?

Do you use CGI with mod_perl?

Edit: Just looked at your comments regarding SSI. Remember that SSI directives can run Perl scripts themselves. See what CGI is trying to run?

Does it depend on another server or service?

0
source share

All Articles