CLI in PHP6

On Thu, 6 Oct 2005 10:48:51 +0200, in php.internals r.korving@xit.nl ("Ron Korving") wrote:

Jani mentioned in http://bugs.php.net/bug.php?id=34483 : "Running a PHP for 24 hours (under windows) is REALLY not supported or suggested. It's definately nothing to do with PHP but your OS." (and "Try this on a real OS, like Linux") Maybe this was what you were thinking of. I can't see any reason for that statement, though.

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