php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #4049 Document Contains no data (different this time?)
Submitted: 2000-04-05 10:59 UTC Modified: 2002-10-01 13:27 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: marc at marcg dot net Assigned:
Status: Wont fix Package: Reproducible Crash
PHP Version: 3.0.15 OS: Solaris 2.6
Private report: No CVE-ID: None
View Developer Edit
 [2000-04-05 10:59 UTC] marc at marcg dot net 
I'm having the old "Document Contains No Data" problem
on Solaris 2.6 running Apache 1.3.12 w/ SSL, Jserv, and
PHP modules compiled (as DSO).

I have read the FAQ, and previous bug reports and think
this could be a different problem.  I've increased the
number of file descriptors in the kernel to 1024.  The
ulimit -a output looks like this:

core file size (blocks) unlimited
data seg size (kbytes) 2097148
file size (blocks) unlimited
open files         1024
pipe size (512 bytes 10
stack size (kbytes)  8192
cpu time (seconds)  unlimited
max user processes   16389
virtual memory (kbytes)  unlimited

I have about 175 (name based) virtual hosts and it 
grows more every day.  Each virtual host uses
up 3 file descriptors for log files since we write
both to the top level log and the specific virtual
host access log, and once to the specific virtual
host error log.

I can configure the virtual hosts down to 79 and
PHP works fine.  I'm testing with a simple "hello
world" script.  Anything above 79 virtual hosts
gives me the document contains no data.  

I've compiled PHP with MySql, Oracle, Sybase, Postgres,
and xml support turned on.  No error messages appear
in any of the log files.

I don't think the file descriptor limit is being reached
since it's set up to 1024.

Any ideas?

-Marc

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-04-05 17:19 UTC] marc at marcg dot net 
BTW,  I've implemented a kludgy workaround that only
works because not all of the virtual hosts on the
web server use PHP.  I've started up a new web server
instance on a new port (8080) and configured only those
virtual hosts that use PHP as duplicate virtual hosts
in this new 8080 web server.  I then redirect all
requests for *.php3 URLs to the 8080 server using the
RedirectMatch apache directive like this (inside the
PHP enabled virtual hosts):

RedirectMatch (.*).php3 http://www.vhost1.com$1.php3

where vhost1 is the name of the virtual host.

While this works as an interim solution I would much 
rather be able to run only one instance of the web
server on one port (as it should be).  Less headache
and confusion for the administrators.

I'm posting this in case it helps others in the same
predicament as myself.

-Marc
 [2000-04-05 17:21 UTC] marc at marcg dot net 

oops...
that RedirectMatch above should be:

RedirectMatch (.*).php3 http://www.vhost1.com:8080$1.php3

(Gotta have the port there!)

-Marc
 [2002-10-01 13:27 UTC] hholzgra@php.net 
We are sorry, but can not support PHP 3 related problems anymore.
Momentum is gathering for PHP 5, and we think supporting PHP 3 will
lead to a waste of resources which we want to put into getting PHP 5
ready. Ofcourse PHP 4 will will continue to be supported for the
forseeable future.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Apr 21 06:01:27 2025 UTC