That's because you have more problems than you know. Basically it mostly boils
down to RH putting things in non-default places.

So I've gathered. :-) I've had no end of problems getting various things upgraded on this box, primarily because of the non-standard tack RH has taken with a number of things (try compiling SSL into Apache - pain in the <insert sensitive anatomical descriptor here>. I'm >this< close to ditching RH altogether. I've been with RH for years, but I'm getting to old to spend so much time futzing around with things.

> As per his suggestion, I went into php.ini and changed the default mysql
> socket to
>          mysql.default_socket =/var/lib/mysql/mysql.sock
> Then, I rebooted the system, since I'm guessing changes to php.ini aren't
> dynamic (like everything else that parses a config file isn't).

Hmm, I see you're used to the Windows philosphy of rebooting everytime you
"move your mouse" so that the "changes can take effect". All you need do is
restart Apache.

Whoops - yup. :-)

> But, this didn't work.  Two possible answers:


> 2) but, perhaps its simply because changes to php.ini aren't being read.

That explains why your changes to mysql.default_socket have no effect.

> In
> fact, this might also be the case:  when I run info.php, I get the
> following for the mySQL bits:
> Active Persistent Links    0
> Active Links    0
> Client API version    3.23.49
> MYSQL_MODULE_TYPE    builtin
> MYSQL_SOCKET        /tmp/mysql.sock
> MYSQL_INCLUDE    no value
> MYSQL_LIBS       no value

> So, I have a look at the top bits from the info.php output. It tells me
> that the Configuration File (php.ini) Path is /usr/local/lib. Not /etc.
> But, copying php.ini from /etc to /usr/local/lib doesn't seem to have done
> the trick.

The output from phpinfo() will give the definitive location for where PHP
expects to find its php.ini. Did you restart webserver? Search php-general
archives for more info about php.ini.

I've done that, and the thing I've tried which seems to have helped somewhat is to put a configure directive into my PHP compile that explicitly tells PHP where to find php.ini. I'd seen it before, but again, never had to use it. But, at least now, info.php is now showing me that php.ini is being readin properly.

> So, something more fundamental. And (tada) I think its because I have two
> versions of PHP on the machine. The old one (4.3.2-19ent) that comes with
> RH Enterprise, and the version I compiled from the PHP 4.3.10 tarball. I
> can confirm that I have 2 binaries.
> So, suggestions? I'm total confused by all this. I don't want to use 4.3.2,
> since its got a number of security issues that were corrected with
> 4.3.10.  Should I simply re-install, but try to make sure PHP is NOT
> loaded, and then do it manually myself from the tarball? Or is there a way
> I can get everything to work with the 4.3.10 installation, and ignore the
> older 4.3.2?

Although not strictly necessary it is however strongly recommended that you do
remove RH's PHP, and if you're feeling brave I suggest removing Apache too
and install both from source, just follow the instructions in manual. And
while you're at it you might as well ditch RH's MySQL and install MySQL's own
RPMs. That way you can keep on top of all the updates that RH7.3 won't be

Well, getting around the default Apache install is trivial (already done that), since the httpd.conf file is very tightly linked to the server daemon httpd. What struck me as odd is that PHP was starting up even though it wasn't reading the php.ini file (until I told it where to look). This is partly what was tripping me up. Strange....this couldn't happen with httpd.

As for uninstalling RH's PHP and mySQL, I'll probably give that a try. I can't afford to have the server offline, but none of my current mission critical functions require PHP or mySQL, so as long as rpm -e for php and mysql doesn't break anything, I'd be willing to try it.

Thanks again to Jason for his various suggestions, and not mention RTFM (or any synonym thereof) even once.

I'll stay on this. I hate letting the evil empire (RH, not Micro$oft on this occasion) beat me. But I don't have enough hair left to keep pulling it out either.

PHP Database Mailing List (
To unsubscribe, visit:

Reply via email to