PHP woes

RimBlock

RimBlock

RimBlock

Associate
Joined
10 Nov 2004
Posts
2,237
Location
Expat in Singapore
Hi,

I am trying to compile PHP to include PCNTL for multi-threading.

The version in the CentOS repository is 5.3.3. which I have installed but which does not exist on the PHP site as a source download.

I have downloaded the latest version (5.4.8) and have compiled following the instructions here.

After restarting Apache (hhtpd) PHPInfo reports version 5.4.8 but the command line reports 5.3.3.

Which php reports
Code: 
/usr/local/bin/php

php -v reports
Code: 
[localhost ~]# php -v
PHP 5.3.3 (cli) (built: Jul  3 2012 16:53:21)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
[root@localhost ~]#

php -v /usr/local/bin/php
Code: 
[localhost ~]# php -v /usr/local/bin/php
PHP 5.3.3 (cli) (built: Jul  3 2012 16:53:21)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
[root@localhost ~]#

php [script] works fine

/usr/local/bin/php [script] reports
Code: 
Warning: mysql_connect(): No such file or directory in /var/www/nnplus/www/lib/framework/db.php on line 21
fatal error: could not connect to database! Check your config.

I have confirmed the sockets are correct

ls -l /var/lib/mysql/mysql.sock
Code: 
srwxrwxrwx. 1 mysql mysql 0 Dec 15 13:45 /var/lib/mysql/mysql.sock

grep sock /etc/php.ini (irrelivent lines returned removed).
Code: 
mysql.default_socket = /var/lib/mysql/mysql.sock
mysqli.default_socket = /var/lib/mysql/mysql.sock

So, two things...
  • Why is the 'which php' version different to the php version reported by doing a -v with the php listed in the which php return ?.
  • Why is the mysql connect not working ?.

Any ideas / suggestions most welcome.

RB
 
To be honest I'd have removed the CentOS provided PHP completely
if you are also installing it from source. If you are using packages which rely on it then this may be slightly non-trivial but should be doable (and you'd probably want to blacklist the PHP package(s) in the YUM configuration so that they are not pulled in as a needed pre-requisite in the future).

Whatever the which command is reporting the php -v outputs are reporting the OS installed PHP rather than the one which you have compiled and placed in /usr/local/bin (and I think you'll find that it is ignoring you path to the new executable in the third quoted output and is just reporting on that being run).
 
I aliased php to /usr/local/bin/php and get the error but the problem I have with removing PHP totally is that I can roll back and it is working but with the new version (via an aliased PHP) it will not connect to the database.

Now the back end scripts are working with the old PHP but the web front end is not as it is using the new php.

I am also getting which ever version of PHP I am using but the old version is still working.
Code: 
[localhost ~]# php -i | mysql
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

Even if I set a user and password in php.ini I still get the same response as above.

RB
 
ok, a reboot seems to have cleared links to the old version.

Problem is that the new version is not working.

Restarting Apache is also giving this message...
Code: 
[localhost /]# service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd: [Sun Dec 16 09:05:29 2012] [warn] module php5_module is already loaded, skipping
                                                           [  OK  ]

Looking in the /etc/httpd/config/httpd.conf I only see 1 line with php5 in it.

RB
 
Ok, /etc/httpd/conf.d/php.ini was also loading php5. That has got rid of the message for Apache restart.

The newly compiled PHP was also looking in the wrong place for the php.ini. I have recompiled with the correct path for the .ini file.

The DB connectivity is working but a Pear error has come up.
Code: 
PHP Strict Standards:  Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in /var/www/nnplus/www/lib/binaries.php on line 249

I am unclear as to how to either conform to the strict standards (not my php code) or disable the check.

Any suggestion most welcome.

Thanks
RB
 
I'm pretty sure the PEAR packages you want aren't supported in PHP 5.4. You might be able to get them to work, but unless you're being forced to use them for some reason, why don't you just use the PDO class?

My understanding is you also didn't need to replace the entire PHP, just compile and enable the pcntl extension itself. If you need to use PEAR-DB/MDB2 then I'd rollback unless theres something forcing you to be on 5.4. I'd assume you'd prefer to have security updates as it is anyway.

http://serverfault.com/questions/158113/installing-pcntl-module-for-php-without-recompiling
 
Last edited:
aln said:
I'm pretty sure the PEAR packages you want aren't supported in PHP 5.4. You might be able to get them to work, but unless you're being forced to use them for some reason, why don't you just use the PDO class?

My understanding is you also didn't need to replace the entire PHP, just compile and enable the pcntl extension itself. If you need to use PEAR-DB/MDB2 then I'd rollback unless theres something forcing you to be on 5.4. I'd assume you'd prefer to have security updates as it is anyway.

http://serverfault.com/questions/158113/installing-pcntl-module-for-php-without-recompiling
Click to expand...

Ok, interesting.

I am running an application that requires Pear to be installed and worked fine with 5.3.3. As I wanted multi-threading enabled for some processes and these processes reported the need for PCNTL I had a look for the easiest way to incorporate it.

I had a look at the link you posted but like the original poster, I could not get PCNTL from Yum and the source for 5.3.3 is not availabel on the PHP site so I went with the most recent which is 5.4.

I am still getting the "Non-static method PEAR" warning but the processes seem to be running and working fine including the multi-threading. The warning is just an irritant.

I have tried changing the error reporting variable in the PHP.ini but that has made no difference.

RB
 
aln said:
How many different versions of the error are you getting? You could always fix the code or use an @ to quash the error, but the source for 5.3.3 is here:

http://museum.php.net/php5/php-5.3.3.tar.bz2
http://museum.php.net/php5/php-5.3.3.tar.gz
Click to expand...

THanks,

Just the same error but on multiple lines where the function "iserror()" is called.

PHP Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in /var/www/nnplus/www/lib/binaries.php on line 249

I suspect it is trying to report an issue using isError() and although it appears to be working to some extent I believe there is stull an underlying issue which is being hidden by the calls to isError not working.

I am not a PHP programmer / developer and have limited time so learning the language would be a push but I am fairly familar with Linux (RHEL based) systems.

I didn't spot any errors in the compilation but there were a couple of warnings. I dumped the last build output to text files so will try and go through them tonight. Problem is that there are a few thousand lines. I will give a grep for 'error' or 'warning' first. Anything else worth greping for before going through the logs line by line ?

Thanks
RB
 
It means isError() isn't defined as a static, thus should be called with the -> as opposed to ::. The main problem with fixing it, is you probably haven't initialized the PEAR class in a usable way and the libs probably use it quite a bit internally.

I don't know for sure, but I'm guessing its a backwards compatiblity thing as those libs historically worked and don't seem to whine in my version. I guess the fact its ignoring your error reporting value is a PHP bug though.

The code might still be working, but like I said previously, if I were you, I'd install from yum and add the module as described in the link. Course, you'll run into the problem again when your OS jumps to a later version, but hopefully the libs* will be fixed by then.

*I didn't actually see the answer with regards to whether or not its using PEAR-DB or not. PEAR-DB "has been superseded", I'm not sure if it'll be fixed.
 
Two things came to light last night.

Firstly the isError() issue was sparked as there were problems with a server I was connecting to and now I am connecting to an alternative they have gone, presumably as there is no error to report anymore.

Secondly, things do seem to be working fine with this compilation baring the error reporting :D.

The database is MySQL. Connectivity to it seems fine once I worked out it was looking for the config file (php.ini) in the wrong place and not reporting that it could not find it.

Looking in the threads, it seems the error reporting issue has been around for 5+ years and is unlikely to be fixed anytime soon what with the PHP and Pear developers each blaming each other for it occuring.

Thanks for the replies :).

One other thing... I have now compiled the source for PHP 5.4. How do I install the compiled source on another machine ?. I had to install all sort of dev bit and pieces on this VM to compile and I would rather remove them and so may build another VM and transport the compiled version across but am unclear on what I need to copy across or how to package for distribution.

RB
 
RimBlock said:
Two things came to light last night.

Firstly the isError() issue was sparked as there were problems with a server I was connecting to and now I am connecting to an alternative they have gone, presumably as there is no error to report anymore.

Secondly, things do seem to be working fine with this compilation baring the error reporting :D.

The database is MySQL. Connectivity to it seems fine once I worked out it was looking for the config file (php.ini) in the wrong place and not reporting that it could not find it.

Looking in the threads, it seems the error reporting issue has been around for 5+ years and is unlikely to be fixed anytime soon what with the PHP and Pear developers each blaming each other for it occuring.

Thanks for the replies :).

One other thing... I have now compiled the source for PHP 5.4. How do I install the compiled source on another machine ?. I had to install all sort of dev bit and pieces on this VM to compile and I would rather remove them and so may build another VM and transport the compiled version across but am unclear on what I need to copy across or how to package for distribution.

RB
Click to expand...

Assuming its the very same distro, you can copy the binaries. Still more than a pita in my opinion. I assume its installed into /usr/local instead of /usr/bin? Theres also generally stuff in /usr/share, though I'm half guessing because I don't use CentOS. Might wanna build an RPM if its something you do often.

Regarding the threads about this years ago, I saw them too, but theres a big gap inbetween the recent ones and the old ones, so I assumed it wasn't exactly the same thing, because that'd make PEAR even more of a joke than when it upgrades my installs to beta versions. :p

If you're thinking about going live with it spitting that error all the time, make sure you got disk usage monitoring.
 
Last edited:
aln said:
Assuming its the very same distro, you can copy the binaries. Still more than a pita in my opinion. I assume its installed into /usr/local instead of /usr/bin? Theres also generally stuff in /usr/share, though I'm half guessing because I don't use CentOS. Might wanna build an RPM if its something you do often.

Regarding the threads about this years ago, I saw them too, but theres a big gap inbetween the recent ones and the old ones, so I assumed it wasn't exactly the same thing, because that'd make PEAR even more of a joke than when it upgrades my installs to beta versions. :p

If you're thinking about going live with it spitting that error all the time, make sure you got disk usage monitoring.
Click to expand...

I did a build to a directory off the /tmp and then tar'd the results and untar'd on the new box from / which put all the parts in the right places. The problem was some of the missing lib files included in the compile but not as standard on CentOS. I started copying them over one by one but after 4 or so I just copied the whole lib folder contents over and that was a mistake :). SSH stopped working due to an incompatible lib. I ended installing all the dev stuff and just rebuilding on the box. Shame, would have thought you could have packaged it up fairly easily for installing on another machine but seems to be not the case.

I think the point on sidk space is a good call. I will need to check logs for build up of that error message or just redirect std err to /dev/null but then that may cause problems if any real issues come up. This is only a personal home machine so not business critical ;).

RB
 
You must log in or register to reply here.
Back
Top Bottom