3

I restarted my apache daemon today to reload the config file, but after this i began to see many php zombie processes on the system. The amount varies from 10 to 30 and they all take a little slice of CPU while they die. Where should I begin to debug this problem?

The modification I made was reducing Max Requests Per Child from 0 (massive memory leaks) to 1000. I think that the php processes are from a script that receives data from "dumb" devices, ie. they send a request with GET parameters and don't care about the result.

Some data:

uname -a

# uname -a Linux <hostname> 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27 19:49:27 BST 2011 x86_64 x86_64 x86_64 GNU/Linux 

ps -aux | grep php

# ps aux | grep php user1 5709 1.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5717 1.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5721 1.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5722 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5723 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5724 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5725 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5729 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5731 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5737 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5760 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5778 1.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5793 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5798 1.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5800 1.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5833 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5850 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5870 3.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5875 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5876 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5877 2.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5886 0.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5926 0.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5939 0.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5941 0.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5961 0.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5962 0.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5973 0.0 0.0 0 0 ? Z 12:15 0:00 [php] <defunct> user1 5977 0.0 0.2 106836 8680 ? R 12:15 0:00 /usr/bin/php /home/user1/public_html/<script>.php root 5981 0.0 0.0 103228 836 pts/0 S+ 12:15 0:00 grep php 

free

# free -m total used free shared buffers cached Mem: 3831 3173 658 0 183 2502 -/+ buffers/cache: 487 3344 Swap: 4031 7 4024 

uptime

# uptime 12:18:10 up 105 days, 23:21, 1 user, load average: 0.23, 0.20, 0.18 

Anything else needed to help me debug this?

3 Answers 3

4

It's not a problem. Zombies don't take up CPU, or memory, or anything other than process table slots. The zombies aren't hanging around for very long, you've said, so all that is happening is that the Apache master process is doing things other than waiting around for child processes to exit, so it's sometimes taking a little while before the terminated children get reaped.

2
  • Ok, thanks for providing some peace of mind. I Just started wondering about possible configuration errors because this stated happening right after reloading the config. Well, if it works, don't fix it, right? :) Commented Apr 27, 2012 at 9:39
  • It would have been happening previously whenever a child process was deemed "surplus to requirements", but because you weren't spawning and reaping child processes nearly as often you didn't notice it. Commented Apr 27, 2012 at 9:42
0

A zombie prozess is just a process which parent already died/was killed, and was not tidied up yet.

If this happens during a service restart its perfectly normal. You should read up on linux process states, rough info just here:

  1. Running: This is a state where a process is either in running or ready to run.
  2. Interruptible: This state is a blocked state of a process which awaits for an event or a signal from another process
  3. Uninterruptible: It is also a blocked state. The process is forced to halt for certain condition that a hardware status is waited and a signal could not be handled.
  4. Stopped: Once the process is completed, this state occurs. This process can be restarted
  5. Zombie: In this state, the process will be terminated and the information will still be available in the process table.

If it happens however during regular usage of your webserver (we are talking about php processes after all), you might fix this temporarily with a cronjob every minute doing an apache graceful restart (service apache2 reload), but this does not solve the underlying problem eating away your available slots.

In the second case you need to discern which hosting is causing the zombies and the application has to be fixed. 99% of such zombies are caused by badly programmed websites.

0

Please add code pcntl_wait() after forking the process with pcntl_fork()

$pid = pcntl_wait($status, WNOHANG); int pcntl_wait ( int &$status [, int $options ] ) 

The wait function suspends execution of the current process until a child has exited, or until a signal is delivered whose action is to terminate the current process or to call a signal handling function. If a child has already exited by the time of the call (a so-called "zombie" process), the function returns immediately. Any system resources used by the child are freed

3
  • I was not forking PHP processes inside PHP, I adjusted the Apache config. Commented Aug 20, 2019 at 5:28
  • @onik can you post what apache config changes you made? Commented Nov 5, 2020 at 12:10
  • @user1130176 I can't really remember, it was 8 years ago... Sorry! Commented Dec 16, 2020 at 14:50

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.