Friday, 15 October 2010

Getting annoyed with php not working

Today I was still doing website work, trying to get the user's country from their IP address. I thought that I finally had everything working with my latest installs of nginx and php, and so decided to try activating them on the live server (I'd already installed them on there).

Unfortunately the CentOS init script for nginx wouldn't start it as it already thought nginx was running (the old installation was still running). So I had to deactivate the old one (thus making my websites inaccessible) before I could even test whether the new installation would work okay.

After finally getting them (nginx and php) up and working on the web server, I tried my websites and they loaded okay. But when I tried to send myself a message using the contact form on one of the websites, it made php stop responding. So when I realised this I had to make the changes to go back to the old nginx and php. So my websites were down for a few minutes.

Next I spent a while trying to find what the problem was. I found that the problem only occurred when the send function of the PEAR Mail class was used. So I spent a long time trying to find what the problem with this was, and why would it cause php to crash and become unresponsive?

I thought maybe the problem was php-fpm, so I tried to use spawn-fcgi to start php instead. But the php-cgi binary didn't exist.

So I tried re-installing PHP using --enable-fastcgi but got a message that it didn't recognise that option. Next I tried --enable-cgi (as well as --enable-fpm). configure didn't give any complaints, but when I had finished installing it (which takes quite a while), I found that it hadn't created the php-cgi binary. So I tried again, but this time without --enable-fpm, and it built with the php-cgi binary okay.

After modifying the php spawn-fcgi init script to work with the new installations of spawn-fcgi and php, and a few hiccups, I got php up and running through spawn-fcgi. And guess what? Yep, same problem as php-fpm, goes braindead when I use the pear mail class to send an email.

I thought maybe I should try using the latest PEAR Mail class in case the older one wasn't compatible with PHP 5.3.3. So I looked on the PEAR website, and after reading through a few of the docs saw they said you needed to download pyrus.phar, and then use that to install the PEAR modules.

So I downloaded the pyrus.phar and tried to use it as directed in the docs to download the SMTP class first. pyrus said that since it was a first run I should specify where the PEAR stuff should go. I left it at the default, but it then installed a load of folders into the main php folder. Turns out it just specifies the current working directory as the default. Doh!

I looked back up at all the pyrus options that had been printed out as part if the initialization process, but didn't see anything about changing the defaults or re-initializing. Near the top though it did say
Usage:
  php pyrus.phar [/path/to/pear] [options]
  php pyrus.phar [/path/to/pear] [options] <command> [options] [args]
It had quite a few errors because it hadn't loaded php.ini as well. Rather than always using -c /path/to/php.ini when using php pyrus.phar, I thought I would just move php.ini to php/lib, where it is automatically looked for by default. Of course, this meant modifying the spawn-fcgi php init script as well to point to the correct location for php.ini.

Now I deleted all the new directories that had been created when I installed the SMTP module using pyrus and tried again. the usage examples show /path/to/pear as an option, but aren't explicit as to what this. Is it the pear file in php/bin, or is it /php/lib/PEAR? I thought probably the latter, so tried that.

But this just created a new folder in the PEAR directory called php, and then in that was the Mail class. This didn't seem right. I thought the correct directory to install into must be php/lib, then it should actually be installed into php/lib/php. So I deleted the new folder and tried again, but now got an error (well actually, lots of errors), which ended up
PEAR2\Pyrus\ChannelRegistry\Exception: Unable to process package name
 PEAR2\Pyrus\ChannelRegistry\ParseException: Exception: corrupt registry, could not retrieve channel pear.php.net information
Googling for this error didn't come up with anything except the code that generates this error. Very helpful!

So I tried downloading pyrus.phar again. I'm not sure whether the registry is saved and updated within the pyrus.phar file or somewhere else, but I thought it was worth a try. On the PEAR2 website it says
Pyrus is a tool to manage PEAR packages. Pyrus simplifies and improves the PEAR experience.
If pyrus simplifies installing PEAR packages, it must have been an absolute nightmare to install them before!

After downloading pyrus.phar again, I still got the same errors. I tried removing the $HOME/.pear directory in case it was a problem with a file in there causing the errors, but still got the same error messages.

After restarting the VM I tried again, and pyrus now acted as if it hadn't been activated before. But I then got a load of error messages during the activation process.

I recompiled php yet again, copied the pyrus.phar again, but still the same errors. I checked the PEAR website in case the latest version of pyrus is buggy (the error messages seem to be to do with an xml parser inside pyrus). But I couldn't find any downloads of pyrus other than the latest one on the homepage.

1 comment:

Unknown said...

I find that this is generally the feeling that I get too. I love that the PHP community is making advances in packaging and re-usable code, but the documentation is severely lacking, and the packaging tools seem a little 'hinky'. Even documentation on WHERE TO CONTRIBUTE DOCUMENTATION is hard to find.

Compare this to ruby gems documentation and `gem install foo`. I hope we - as a community - can eventually get to that point of centralization and standardization, but I think we have quite a bit of work cut out.