There was once (can't remember when exactly, so it must be a long time
ago)
here on PHP CLI scripts in which it came forward that one should not rely
on
such a script to run forever. And it's true; the scripts sometimes
magically
and suddenly die. Now I have no clue where this instability (for lack of a
better word) comes from, but could it be possible for this to be resolved
for PHP6 so that PHP becomes an extremely viable solution for CLI daemon
scripts?
The short answer is that PHP plays a little "fast-and-loose" with the data
it tracks because it has no idea what you plan on doing with that data. In
*theory* allocated resources get cleaned up within a request the minute they
no longer have any possible relevance (i.e. A database connection is created
within a function, then that function leaves making the variable it was
placed in no longer accessible from anywhere).
In 99% of the engine/core/exts this happens seemlessly, however there *may*
be (and most likely is) a lingering leak somewhere because a file descriptor
wasn't closed, or a couple bytes of memory wern't freed. In a "normal"
webserver environment these resources get forcibly cleaned up by the
end-of-request garbage collection process so they don't get noticed by the
bulk of PHP users out there. In a long-running daemon process this GC phase
never triggers and those piccune leaks pile up.
Things you can do to help locate these issues:
#1) Compile PHP with --enable-debug and run a version of your daemon
designed to kill itself off after a short period (how long may vary: a
minute, an hour, a day, a week.... try different periods). At the end of
execution, Zend will report what memory was leaked by the request and where
it was allocated. Though often the allocation was done by the engine but
the free was the responsibility of an ext, so this is only partially useful.
#2) Do the same as #1, but run the process through valgrind enabling
reporting of memory leaks and unclosed file descriptors and other debug
data. This is much more verbose output, but it helps track down the origin
of such leaks more precisely and efficiently.
#3) Report back what you find. The best way to do this is to post (A) Your
code, (B) Output from #1, and (C) Ouput from #2 on a webserver somewhere and
provide links to those pages in a message to php.internals. At that point,
someone here will either:
(I) identify the problem and just fix it,
(II) Ask for more information,
(III) Provide some insight but ask that you reformat the problem into a bug
report,
(IV) Shrug and say "I dunno", and/or ignore it
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
