# CLI in PHP6 - Thread: https://externals.io/message/19430 - Original archive: https://news-web.php.net/php.internals/19430 - Started by Ron Korving on 2005-10-06T08:48:51+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #19430 — Ron Korving — 2005-10-06T08:48:51+00:00 URL: https://externals.io/message/19430#19430 Hi, 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? Thanks, Ron Korving --- ## #19438 — Peter Brodersen — 2005-10-06T10:33:16+00:00 URL: https://externals.io/message/19430#19438 · In reply to: #19430 On Thu, 6 Oct 2005 10:48:51 +0200, in php.internals r.korving@xit.nl ("Ron Korving") wrote: >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? 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. -- - Peter Brodersen --- ## #19439 — James Aylett — 2005-10-06T10:57:33+00:00 URL: https://externals.io/message/19430#19439 · In reply to: #19438 > 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. For early consumers versions of Windows (95, 98, ME) I wouldn't recommend running a process for that long if you rely on it. For NT-based versions, including consumer editions, there should be no problems in running scripts for as long as you like. This particular bug report was against Windows 2000 Server, which should have no problems. I would heavily dispute the statement that it's definitely the OS and not PHP - there are plenty of processes that run happily for months on W2K Server. James -- james aylett, chief technical architect tangozebra 020 7535 9814 ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ --- ## #19440 — Ron Korving — 2005-10-06T11:50:48+00:00 URL: https://externals.io/message/19430#19440 · In reply to: #19439 I've had PHP scripts die after weeks or months on Linux without an obvious reason, and honestly I'm a little bit puzzled on how to debug the situation. Any suggestions? Ron "James Aylett" schreef in bericht news:20051006105733.GJ11922@tangozebra.com... > > > > […] > > For early consumers versions of Windows (95, 98, ME) I wouldn't > recommend running a process for that long if you rely on it. For > NT-based versions, including consumer editions, there should be no > problems in running scripts for as long as you like. > > This particular bug report was against Windows 2000 Server, which > should have no problems. I would heavily dispute the statement that > it's definitely the OS and not PHP - there are plenty of processes > that run happily for months on W2K Server. > > James > > -- > james aylett, chief technical architect > tangozebra > 020 7535 9814 > > ________________________________________________________________________ > This e-mail has been scanned for all viruses by Star. The > service is powered by MessageLabs. For more information on a proactive > anti-virus service working around the clock, around the globe, visit: > http://www.star.net.uk > ________________________________________________________________________ --- ## #19449 — Sara Golemon — 2005-10-06T17:57:43+00:00 URL: https://externals.io/message/19430#19449 · In reply to: #19430 > 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