You’re saying that the parent never responds to signals during that loop? It sounds silly, but what happens if you put some other operations in that while loop, like a for-loop? I’m not convinced sleep(1) is a “tickable” statement…

Also, try substituting your while loop, for a while(true) loop, then call waitpid without no-hang…. see what happens then.

while (pcntl_waitpid($pid2, $cstatus, WNOHANG) == 0) {
sleep(1);
}

I’ve confirmed the loop runs fine by adding an echo in the function, yet during this process the daemon never responds to any signals sent to it.

To clarify:
Application – forks daemon
Daemon – forks child process, waits for it to return. Child process assumes a different uid/gid which is why the fork.

Daemon responds to all signals up until the child fork, at which point it won’t respond anymore.

With PHP5.3+ declare(ticks=1) is deprecated, that means that the signal handlers are NOT registered to be called. You have to manually trigger them by adding to your primary loop the following:

Before:
while ( $var === true ) { // do something cool }

After:
while ( $var === true && pcntl_signal_dispatch() ) { // do something cool }

pcntl_signal_dispatch() will then fire all signal handlers. See http://bugs.php.net/bug.php?id=47198 and http://www.php.net/manual/en/function.pcntl-signal-dispatch.php for further details.

Inside your main process loop it is extremely important to check for signals before AND after your main process. That will allow you to cleanly shutdown, restart etc your daemon process.

If processing very large XML files i.e. >100MB use xmlreader() and run that process separately NOT as a daemon; use a daemon though to control when the files are processed.

Avoid at all costs reciprocal references in long running scripts e.g. passing $this into sub-objects so you have references between objects. You will run out of memory as the objects will never be destroyed (this is possibly fixed in PHP 5.3). Similarly avoid using simplexml foreach loops – they leak memory too. Use for loops instead (which don’t).

As has been mentioned in the article already, and really needs re-iterating: NEVER open a resource before forking the process. Do only basic initialisation and then only when your process has forked should you create db connections, file pointers etc. This will avoid any nasty hard to track bugs with already opened resources dropping out of scope or being prematurely killed.