Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 79683

Summary: [RFE] RH8.0 unstable when php is installed
Product: [Retired] Red Hat Linux Reporter: redhatbug
Component: phpAssignee: Joe Orton <jorton>
Status: CLOSED WORKSFORME QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0Keywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-07-08 15:54:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description redhatbug 2002-12-15 01:20:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 

Description of problem:
This is a request for an enhancement to solve a serious unstable problem.  I 
was told when I contacted Red Hat to post this issue here with [RFE] at the 
start of the summary.

Have the ability to install PHP with Apache 1.3 instead of Apache 2.0.  RedHat 
8.0 only gives the option to install Apache 2.0, however PHP does not run 
stably yet on Apache 2.0 and the developers still are strongly are 
suggesting that you do not use Apache 2.0 with PHP in a production environment.

I'd like to upgrade my servers to the newer RH8.0 version to take advantage of 
some other improvements but because most of my servers use PHP in production 
environments I can not risk my business by putting an unstable setup of PHP in 

Please consider adding this to the RedHat network so I can install a stable 
http/php server on RedHat 8.0

I know that Apache 2.0 is not considered unstable anymore on it's own so it'd 
be great to have the option to put Apache 2.0 or 1.3 that way my production 
sites can still have the stable 1.3/php combination.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.This is a request for enhancement to solve a non-production quality setup 
you have with PHP (it's the fact php installs with Apache 2.0 in which php 
does not run stable enough yet for a production/business environment

Additional info:

Comment 1 Cristian Gafton 2002-12-17 20:15:05 UTC
Assign to the right product. Fix priority.

Comment 2 Joe Orton 2002-12-17 21:19:50 UTC
Hi - just to clarify, this is something you have actually experienced, i.e. you
are seeing server crashes when using PHP in 8.0?  If so, these are obviously
things we will fix, but some more details would be useful (e.g. which extension
modules are in use)

Comment 3 Joe Orton 2003-06-13 11:18:36 UTC
If no details are given about instability problems we cannot fix them; please
file bugs on reproducible problems.

Comment 4 redhatbug 2003-06-13 16:20:06 UTC
I don't have those anymore as I moved back to RH 7.3 - basically there was 
problems with sessions and memory leaks.

Perhaps you need to contact the actual developers of PHP.  

This is more a poor business choice than a bug as your are installing an alpha 
quality program on a server and labling it as stable.

I don't see how you can install a product (php) on your servers and call your 
servers stable if the developers themselves say their product is unstable when 
installed with apache 2.x.  It even gives this warning NOT TO USE on 
production servers when you compile it with apache 2.x

Comment 5 Joe Orton 2003-07-08 15:54:36 UTC
The warning in the PHP documentation is really inspired by the problems which
you'd find if using PHP with one of the thread-based server models in Apache
httpd 2.0.  The default httpd binary we provide uses the same "prefork" model
(process-based not thread-based) as in 1.3, so this is not a cause for concern.

I'm going to close this bug as there is nothing we will fix here.  Thanks for
your feedback.