PHP5 or PHP4 for apache2-mpm-worker

Is this bug going to be corrected and included in hoary, or we will have to wait
longer?

Not for hoary; it's a massive change which we were worried would be too
destablising so close to release.

Given (numerous) discussions with upstreams at both php.net and zend.com,
this bug may never be resolved (or, not the way people might like it to
be), as the current opinion of upstream is that PHP's Thread Safety
Resource Manager is so poorly-written, it should be completely removed, and
NEVER used in production. Their recommendation for users of threaded
webservers is currently to use CGI or FastCGI.

After enabling ZTS on Debian's PHP builds and triaging a bunch of bug
reports over the last few weeks, while I'm not convinced ZTS is complete
evil, it does seem fairly obvious that it's poorly-maintained and not ready
for prime-time.

Definitely not for 5.10...

Is this still a valid bug? Was it only a Hoary issue? Thanks.

Even in dapper libapache2-mod-php5 forces the removal of apache2-mpm-worker, installing apache2-mpm-prefork instead.

The problem is that on some circumstances apache2-mpm-worker is a must (to handle heavy loads).

Right now I'm using Worker + Fast CGI + PHP5 on a dapper server, that is almost as fast as directly mod_php5 but I would prefer if sometime in the future "mod_php5_apache2_worker" is available.

On several Gentoo's I have compiled mod_php5 for apache worker without any problem, its very stable.

Any news on this? It's been sitting around for an eternity not doing a whole lot.

No news...
libapache2-mod-php5 still requires apache2-mpm-prefork on feisty.

Do you still have this issue with the latest release of Ubuntu ?

Still same issue. libapache2-mod-php5 depends on apache2-mpm-prefork. There is no option for the new apache2-mpm-worker.

$ apt-cache show libapache2-mod-php5
Package: libapache2-mod-php5
Priority: optional
Section: web
Installed-Size: 5588
Maintainer: Ubuntu Core Developers <email address hidden>
Original-Maintainer: Debian PHP Maintainers <email address hidden>
Architecture: i386
Source: php5
Version: 5.2.1-0ubuntu1.2
Provides: phpapi-20060613+lfs
Depends: libbz2-1.0, libc6 (>= 2.5-0ubuntu1), libcomerr2 (>= 1.33-3), libdb4.4, libkrb53 (>= 1.4.2), libpcre3 (>= 4.5), libssl0.9.8 (>= 0.9.8c-1), libxml2 (>= 2.6.27), zlib1g (>= 1:1.2.1), mime-support (>= 2.03-1), apache2-mpm-prefork (>> 2.0.52) | apache2-mpm-itk, apache2.2-common, php5-common (= 5.2.1-0ubuntu1.2), libmagic1, ucf
Suggests: php-pear
Conflicts: libapache2-mod-php4

Ok I'm confirming this, and setting the package to php5.

This is still an issue for Gutsy.

Is there any progress on this issue? This is starting to become a major problem for me and my organisation. We're using mod_perl2 extensively which really works best with the mpm worker, especially at high loads, but we also need to be able to run some php5 scripts. A (technical) explanation why this issue hasn't been resolved yet would be nice.

The explanation is that there are a few PHP extensions that don't work well with threads, but right now most of them (and all the usual ones) work fine.

I think a version of mod_php5 for apache2 threaded should be released with ubuntu, so you can use the much better apache2-worker.

If someone needs a particular php extension that doesn't work with threaded PHP, he will always be able to install mod_php5 prefork version.

Recommended solution is to use fastcgi with mpm-worker.

Yeah, right now I'm using that, but is a pain to configure for novices compared to just install libapache-php5. At least some sample config could be provided in a "libapache-mod-php5-fastcgi" package or similar (that will have fastcgi dependance included)

Now I have to create a /etc/apache2/mods-available/php5-fcgid.conf:

AddHandler fcgid-script .php
<Files ~ "\.php$">
Options ExecCGI
</Files>
FCGIWrapper /path/to/a/php5-launch-script .php

The launch script is:
#!/bin/bash
export PHPRC="/path/to/conf"
export PHP_FCGI_CHILDREN=20
export PHP_FCGI_MAX_REQUEST=5000

exec /usr/bin/php5-cgi

This is much more flexible than just mod_php5 (I could have different launch scripts with different limits, conf directories... for each virtualhost, plus the SuexecUserGroup directive). But as I said Ubuntu should help a little bit more. People expects installing php5 and apache2-mpm-worker to work. And not only it doesn't, but just through unprocessed PHP code to anyone, and thats' is really dangerous.

I'd really like to see something done about this. Throwing perfectly acceptable and highly sought after techniques for optimization is not a good way to promote the server edition of Ubuntu.

If I had to deploy tomorrow, I'd be stuck compiling my entire web server stack!

Holy cow - look how long this bug has been around too!

I want to bump this bug up, too. I've been searching for HOWTOs for the past two days trying to find out how to do this after reading an article (can't find the link in my history now) which showed a three-fold increase in speed with Worker+FastCGI+PHP5. Folks seem to be discussing the benefits, but retaining the solutions. I've not found any similar solutions--they're all different, and I've not been able to get any of them to work.

I followed this and got it to work: http://ivan.gudangbaca.com/installing_apache2_and_php5_using_mod_fcgid. However, my site is MUCH slower--14 seconds to load opposed to approximately one second with Prefork/mod_php5.

Colin, I wrote a how-to "Apache 2 with FastCGI, SuExec and PHP"

It possibly covers more than you need since it sets suexec up for VirtualMin's web-homes as well as the FastCGI/PHP configuration, but it is a full step-by-step-with-code guide based on my own experience.

http://tjworld.net/wiki/Howto/Apache2FastCgiSuexecPhp

@ Guillermo Pérez

I totally agree with you that a "libapache-mod-php5-fastcgi" package should be released to take care of this issue.

"a pain to configure for novices"

My opinion is that "novices" should use mpm_prefork.

Nice howto included with php5-cgi/libapache2-mod-php5 would be nice (anybody volunteers to write one?), but separate package makes no sense to me.

>> My opinion is that "novices" should use mpm_prefork.

No offense but that's a very Debian-esque answer.

Sure most of us can get PHP5 + FCGI to work, but the problem is a lot of ubuntu/debian php webapp pacakges (e.g. phpmyadmin, etc.) use the mod_php5 package in their dependencies rather than the php5 metapackage, and put php directives in their httdp.conf/.htaccess with no <IfModule> lines.

You may be right that another package is not needed. As the php5-cgi + ibapache2-mod-fcgid packages are sufficient. What we need is a clear policy that php webapp packages should depends on the php5 metapackage rather than lipapache2-mod-php5.

Oh I forgot to mention, the problem is if a package requires libapache2-mod-php5, it forces the mpmpork version of Apache. As long as a php package use the php5 metapackage instead of requiring libapache2-mod-php5 directly, mpmworker can be installed.

On Sat, Feb 21, 2009 at 01:27, goofrider <email address hidden> wrote:

> the problem is a lot of
> ubuntu/debian php webapp pacakges (e.g. phpmyadmin, etc.) use the
> mod_php5 package in their dependencies rather than the php5 metapackage,
> and put php directives in their httdp.conf/.htaccess with no <IfModule>
> lines.
>
> You may be right that another package is not needed. As the php5-cgi +
> ibapache2-mod-fcgid packages are sufficient. What we need is a clear
> policy that php webapp packages should depends on the php5 metapackage
> rather than lipapache2-mod-php5.

That's a good point. Would filing a bug on each package to change
dependencies be worthwhile?

How about just modifying libapache2-mod-php5 to depend on apache2 instead of apache2-mpm-prefork?

> That's a good point. Would filing a bug on each package to change
> dependencies be worthwhile?

Yes, but please do that in Debian. There is http://webapps-common.alioth.debian.org/draft/html/ which may interest you.

Just a note: With an introduction of php5-fpm (little bit premature in Ubuntu, but still there), there's really no need to have mod_php5 for mpm_worker. Given that it's still high risk because of thread safety, I doubt it will ever happen now when there is better alternative solution.

Closing based on the above comments.