why does this always happen to me?

[faris]

Well, I've done it again. I've somehow broken something after installing Scott's php and mysql.

** this is on a test system so it doesn't matter **, but I can't figure out what's wrong nor how to fix it, and would appreciate advice.

Basically I started with Plesk 7.14 on RH9 with all updates from fedoralegacy installed via yum.

Everything worked perfectly.

Then I did a yum install php* mysql* (having done an rpm -e php-manual first)

No problems, no errors. The right packages were installed. All looked well. Plesk itself works fine.

But apache doesn't stay up for more than a second.

Last time this happened it was just a Zend Optimzer issue. All I had to do was re-install Zend and all was well.

But this time php works perfectly from the command line, with and without Zend Optimizer installed. So it isn't Zend.

But httpd just won't stay up. It starts but then nothing...

The problem is that I can't find any errors. /var/log/httpd/error_log contains nothing out of the ordinary. No seg faults. Nothing.

I've tried copying the php.ini that came with the rpm into /etc/php.ini just in case. No change. I've tried removing all reference to Zend and the Ioncube loader in the last 10 lines of php.ini. No difference.

Any suggestions? Where else should I look for errors? I just don't get it - the php and mysql rpms don't touch apache, do they, so I assume this has to be a php issue somehow, even though it works fine from the command line?


Faris.

# update
This appears to be reproducable. I had created an image of the system before installing php 4.3.9 and mysql 4 so I went back to that and tried the same thing and had exactly the same result.

This time round I noticed that if I did not comment out the ioncube loader (which is for version4.2 of php) I got a segfault when running php at the command line, just as I would expect. Removing it allows php to run, but httpd just isn't interested.

[scott]

First off these are all great debugging steps (and an image offline too no less). The next one I would take after all the things you just tried would be to comment out the PSA httpd.include in httpd.conf. If it starts up then you'll know its something configuration, or file descriptor related.

Other things you might want to try is to run ldconfig, this probably is not the issue, 95% of the time you'll see the library complaints when you run php from the command line. Then I'd review all the php rpms installed (rpm -qa |grep php) see if you have any mismatches in there.

[faris]

Aha! Thanks Scott.

Well, commenting out the httpd.include didn't help, and all the php stuff looks fine (thanks for putting the commands in, btw- little things like that help a lot when you don't use them every day) and there were no complaints from ldconfig.

But it has helped me to narrow things down hugely, because commenting out the Include conf.d/*.conf almost at the top of the httpd.conf file has allowed it to start.

Unfortunately the "obvious" culprit, php.conf, does not appear to be the cluprit, as even copying the .rpmsave version (created when the new php was installed) over the original hasn't helped. But I there is obviously something it doesn't like in there so I'll keep looking.

## UPDATE

OK. The problem is php.conf in a way


The line it doesn't like is
LoadModule php4_module modules/libphp4.so

Commenting out that line allows apache to run.

I checked the permissiong on the that .so and they look fine and are the same as all the other .so files in there:
-rwxr-xr-x 1 root root 8365583 Oct 15 15:36 /usr/lib/httpd/modules/libphp4.so

So obviously apache does not want to play with php. So now I'm off to look at php.ini again unless you have any other suggestions.

Faris.

[scott]

Hmm, well at this point Id say try compiling the php src.rpm on your system and see if it coexists with that.

[faris]

I'll try that. Should be interesting.

In the meantime, is this significant?

ldd -d /usr/lib/httpd/modules/libphp4.so

gives a load of OK stuff, followd by:

undefined symbol: apr_bucket_type_file (/usr/lib/httpd/modules/libphp4.so)
undefined symbol: apr_pool_cleanup_null (/usr/lib/httpd/modules/libphp4.so)

Faris.

[scott]

yeah thats bad, apr is an internal component of apache. If thats not resolving I'd say its the culprit. I dont suppose you've been using packages from the -unstable channel?

[faris]

Nope. Definitely not. Nothing from the unsable channel. I double-checked just in case.

The installed apache is the latest from the fedora project's updates channel. It was just updated the other day. I've installed it without probs on my live server.

On the previous try I did try installing your high fd apache to see if it made any difference to the problem, but it didn't.

I'll roll back to the image with the older apache and see if I can repeat this with that version.

Thanks for your advice on all this Scott.

Faris.

[scott]

well a recompile might help in this case