Tag: PHP

[FreeBSD]Upgrade PHP 5.5 to 5.6

Posted on by

It is not easy to upgrade PHP 5.5 to 5.6 in FreeBSD. Without proper preparation, the upgrade process may drive you nut. Before you decide to get your hands wet, here are what I recommend you to do:

  1. Back up your files
  2. Test your website in a PHP 5.6 environment on a different server. It is because PHP 5.6 has introduced some backward incompatibilities. Some of the codes written in the prior versions may introduce run time error. See here for more information.
  3. Schedule a down time. Depending on your CPU speed / typing speed / trouble-shooting skill, it may take you an hour.

Background

I am assuming that you use PHP for web purposes (rather than command line / CLI only), and I am assuming that you are using PHP with Apache. Here are the ports you will need to touch:

  • Apache: /usr/ports/www/apache22 or /usr/ports/www/apache24
  • Apache-PHP: /usr/ports/www/mod_php56
  • PHP: /usr/ports/lang/php56
  • PHP Extensions: /usr/ports/lang/php56-extensions

1. Remove the old PHP and extensions

cd /usr/ports/lang/php55
sudo make deinstall clean


cd /usr/ports/lang/php55-extensions
sudo make deinstall clean

2. Install PHP 5.6

cd /usr/ports/lang/php56

#Don't forget enable ZTS if you have threaded Apache.
sudo make install clean

3. Install PHP 5.6 Extensions

cd /usr/ports/lang/php56-extensions
sudo make install clean

4. Test PHP and its extensions

php -v
php -m

Clean up the error by removing the duplicated entries in:
/usr/local/etc/php/extensions.ini

5. Rebuild the Apache-PHP Bridge

cd /usr/ports/www/mod_php55
sudo make deinstall clean

cd /usr/ports/www/mod_php56
#Don't forget enable ZTS if you have threaded Apache.
sudo make install clean

6. Restart Apache

sudo /usr/local/etc/rc.d/apache restart

7. Test PHP using phpinfo

Create a code called test.php to display phpinfo. Verify that everything is okay.

< ?php
phpinfo();
?>

8. Reinstall Apache (optional)

If you experience any problem, try to reinstall the following ports:

Apache: /usr/ports/www/apache22 or /usr/ports/www/apache24
Apache-PHP: /usr/ports/www/mod_php56

That’s it! Enjoy the new PHP!

–Derrick

Our sponsors:

[FreeBSD]PHP does not work after upgrading Apache to 2.2.27

Posted on by

I upgraded the Apache to 2.2.27 on my FreeBSD box via portmaster. The upgrade went very smooth. After the upgrade, I found that Apache no longer rendered the PHP page correctly. In the other words, it displayed the source code of the PHP files instead of executing the code.

Before you start doing anything, please make sure that your website is not accessible from public. For example, most web applications like to include the password information in the source code, which is accessible by public if the PHP engine is failed. You may want to restrict the public access during the fix. The easiest way is to set up a .htaccess file and restrict the access by IP address.

Let’s come back to the fix. For some reasons, Apache/PHP team decide to make something fun to the FreeBSD sysadmin, because they think FreeBSD sysadmin have plenty of spare time. Here is what they decide to do:

Originally, we install Apache first, then we install PHP. When we install the PHP, we pick an option such that the PHP will install a PHP engine used by Apache. In the recent release, they decide to remove the engine from the standard PHP package. For example, if you simply use the portmaster to upgrade your PHP (In my case, PHP 5.4 and 5.5), the engine will be missing. That’s why Apache fails to render the PHP files.

Here is what you will need to do. I suggest you to finish reading the following before doing the fix. Trust me. It may save you couple hours.

First, make sure that Apache is working fine.

If you are using PHP 5.4, make sure that you install this port: /usr/ports/www/mod_php5. If you are using PHP 5.5, install this one instead: /usr/ports/www/mod_php55. Make sure that you select the ZTS option. You can do it by running:

sudo make config

Notice that installing this port will reinstall the PHP package (/usr/ports/lang/php5 or /usr/ports/lang/php55). Make sure that the ZTS option is selected in PHP package as well.

Now try to restart the Apache server. That should make the Apache to render the PHP files instead of dumping it.

#sudo /usr/local/etc/rc.d/apache stop
#sudo /usr/local/etc/rc.d/apache start

Test the PHP files again. If you see the PHP result instead of PHP source code, congratulations! You are 20% done.

Now go back to the command line and run the following:

#List the PHP extensions installed by PHP 
php -m

#Check whether the PHP extensions are loaded properly by PHP
php -v

For some reasons, I noticed that many extensions were missing during the reinstallation, such as sessions, json etc. Let’s install them back:

#For PHP 5.4
cd /usr/ports/lang/php5-extensions

#For PHP 5.5
cd /usr/ports/lang/php55-extensions


sudo make reinstall clean

Don’t forget the pecl and related packages as well. After that, try to restart your Apache server and clean up the php extension configuration:

nano /usr/local/etc/php/extensions.ini

You will see a mess. Try to clean up the duplicated extensions and run the php -m and php -v again.

During the fix, I notice that everything works fine except for MySQL package. Interestingly, when I ran php -m, the mysql was available. However when I ran phpinfo(), it was missing. I found that this problem only happens with PHP 5.4, but not PHP 5.5. Therefore, I decided to remove the PHP 5.4 and loaded PHP 5.5 instead.

Simply repeat the installation and restart the server. If possible, try to reboot the machine.

So here is the summary:

  1. Remove PHP, Extensions and PECL packages (sudo make deinstall).
  2. Restart Apache (sudo /usr/local/etc/rc.d/apache stop; sudo /usr/local/etc/rc.d/apache start).
  3. Verify installed extensions with php -m; php -v; and phpinfo().
  4. Verify the result by loading the pages on the web.
  5. If your page is failed, try to find out which extension is missing by checking the error log, which is typically available in in /var/log/

Hope my solutions help!

–Derrick

Our sponsors:

PHP Network Error

Posted on by

One of my PHP web applications stopped working today. After I investigated the issues, I noticed that this is a very famous, yet unsolved error. I have no idea why it happens, but I do have a work around solution for it. Basically, this article applies to you if you match all of the following:

  • You are using PHP
  • Your web applications talk to other servers via domain name (e.g., example.com rather than 123.1.1.3)
  • You use XAMPP (instead of native Apache, PHP).

Notice that I am not 100% sure whether this has anything to do with XAMPP. But most of problem I experienced happen on XAMPP platform.

And here are some example problems:

  • Getting a file connect using file_get_contents(‘http://example.com/somepage.html’), or CURL etc.
  • Sending emails (SMTP server: ‘mail.example.com’)
  • Connect to a database server via domain name (‘example.com:3306’)

Why this problem happens?

This problem has nothing to do with your PHP code. In fact, the problem happens when PHP tries to look up the IP address of your domain name. Let’s take a look to the following example. Suppose I have the following code:

$data = file_get_contents('http://example.com/test.html')

//process the $data here...

When PHP executes this code, it will try to get the IP address of example.com first, and talk to the server to retrieve the content. This problem happens because PHP is unable to get the IP address of example.com.

Initially, I thought it was my server issues, therefore I tried to ping example.com on the server, i.e.,

#ping example.com

and the result looks fine to me. So the problem has nothing to do with the OS / server. Then I run the following code in PHP

$IP = gethostbyname('example.com');
echo $IP;

Normally, I expect to see the IP address of example.com. If it return ‘example.com’, that means PHP is unable to determine the IP address. That explains why the web application stops working.

Solution #1: Restart XAMPP

Try to restart the XAMPP to see whether it resolves the problem or not:

sudo /opt/lampp/lampp stopapache
sudo /opt/lampp/lampp startapache

This method aims to resolve the situation that the XAMPP was already started but the network was not available. Restarting the Apache server helps to resolve this problem.

Solution #2: /etc/hosts

Since PHP was unable to lookup the IP address, I decided to give some hints to PHP by editing /etc/hosts:

123.1.1.1   example.com
123.1.1.2   anotherexample.com

This is a quick and easy solution. However, if example.com is moved a different IP address, you will need to update the file. It is pain in long term.

Solution #3: Stop using XAMPP

As I mentioned earlier, I notice that this problem happen in XAMPP environment only. I haven’t experienced this kind of problem with native Apache and native PHP. So I guess it may have something to do with XAMPP.

In fact, it is quite easy to switch from XAMPP to native Apache+PHP+MySQL etc. Native applications give you better performance and reliability and most importantly: the packages get upgraded automatically.

Hope it helps.

–Derrick

Our sponsors:

[PHP]How to delete Memcache variables in PHP?

Posted on by

I’ve never thought about deleting a Memcache key is a difficult task. It took me few hours to figure out a working solution. No kidding. FYI, I am using PHP 5.4

Suppose you store a very expensive data into the Memcache, and you decide to delete it later. According to the PHP documentation, it should be very simple:

$memcache_obj->delete('key_to_delete');

or

memcache_delete($memcache_obj, 'key_to_delete');

However, this method only works with scalar variables, such as string, integer, double, float, Boolean etc. It does not work with non-scalar variables such as array, object etc.

I have tried many different ways, such as setting the value to something else, e.g., 

$memcache->set('key_to_delete', 'deleted');

or making the key to expire immediately:

$memcache->set('key_to_delete', 'deleted', 0, 1);
$memcache->set('key_to_delete', 'deleted', 0, -1);

Unfortunately, none of these methods worked in my case (my variable is a non-scalar array). So, I ended up doing it in a low-level way: Bypassing the PECL-Memcache (PHP Library) and talk to the Memcache server directly. Guess what, it works very well. The variable gets deleted!

function MEMCACHE_DEL_HASH($key){
	
	if ($key == '') return FALSE;
	
	$socket = @fsockopen('localhost', 11211);
	$command = "delete {$key}";
	
	fwrite($socket, $command."\r\n");
	fclose($socket);
	
	return true;
}

And it is super easy to call this function:

MEMCACHE_DEL_HASH('key_to_delete');

Feel free to modify this function such that you can pass in the connector, port or do anything you like.

That’s it! Have fun with Memcache.

–Derrick

Our sponsors:

[FreeBSD]How to run PECL Tokyo Tyrant in PHP 5.4

Posted on by

After upgrading to PHP 5.4.3 (which is the first version of PHP 5.4 available in the FreeBSD port), I found that the pecl-tokyo_tyrant could not be compiled. Here is the error messages:

cd /usr/ports/databases/pecl-tokyo_tyrant
sudo make

===>  pecl-tokyo_tyrant-0.6.0 cannot install: doesn't work with PHP version : 5 (Doesn't support PHP 5).
*** Error code 1

Stop in /usr/ports/databases/pecl-tokyo_tyrant.

/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1827: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1867: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_table_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1911: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_query_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:1936: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'php_tokyo_tyrant_iterator_class_methods'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'php_tokyo_tyrant_query_object_new':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2001: error: 'zend_class_entry' has no member named 'default_properties'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'php_tokyo_tyrant_iterator_object_new':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2052: error: 'zend_class_entry' has no member named 'default_properties'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'php_tokyo_tyrant_object_new_ex':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2090: error: 'zend_class_entry' has no member named 'default_properties'
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c: In function 'zm_startup_tokyo_tyrant':
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2166: error: 'php_tokyo_tyrant_class_methods' undeclared (first use in this function)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2166: error: (Each undeclared identifier is reported only once
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2166: error: for each function it appears in.)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2171: error: 'php_tokyo_tyrant_table_class_methods' undeclared (first use in this function)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2176: error: 'php_tokyo_tyrant_query_class_methods' undeclared (first use in this function)
/usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0/tokyo_tyrant.c:2182: error: 'php_tokyo_tyrant_iterator_class_methods' undeclared (first use in this function)
*** Error code 1

Stop in /usr/ports/databases/pecl-tokyo_tyrant/work/tokyo_tyrant-0.6.0.
*** Error code 1

Stop in /usr/ports/databases/pecl-tokyo_tyrant.

Basically, it means that the pecl-tokyo_tyrant is not happy with the new version of PHP 5.4. I’ve tried several methods, including using pkg_add, compiling from source, copying a working tokyo_tyrant.so etc, unfortunately none of these methods works.

Finally, I found that the maintainer of this package has made a new version available(0.6.2) at github. Here is how I did it:

First, go to here to grab the source code. Make sure that you download the tag.gz version because it has the file attribute available.

Second, let’s remove the pecl-tokyo_tyrant from your system. You can either do it in the port or pkg_delete:

From port:

cd /usr/ports/databases/pecl-tokyo_tyrant
sudo make deinstall

Or using pkg_delete:

sudo pkg_delete pecl-tokyo_tyrant-0.6.0

Now, extract the files and compile it from source:

tar -zxvf mkoppanen-php-tokyo_tyrant-0.6.0-2-gb0d7e0c.tar.gz
cd mkoppanen-php-tokyo_tyrant-b0d7e0c
sudo phpize
sudo ./configure
sudo make
sudo make install

and don’t forget to include the .so file in your configuration:

sudo nano /usr/local/etc/php/extensions.ini

Add the following (if not available) to the end of the file:

extension=tokyo_tyrant.so

Finally, let’s restart the Apache:

sudo apachectl stop
sudo apachectl start

That’s it! Have fun with Tokyo Tyrant with PHP 5.4.

–Derrick

Our sponsors:

[PHP/FreeBSD]===>>> The databases/php5-sqlite port has been deleted: Removed from core php ===>>> Aborting update

Posted on by

When PHP 5.4 was available few months ago, I was hesitated to upgrade my FreeBSD box to upgrade to 5.4, because it comes with lots of big changes, including removing LOTS of old stuffs that were available in 5.3 or earlier versions.

Today PHP 5.4.3 becomes available in FreeBSD ports. I guess it is stable enough and I should give it a try, and I am glad that I tried it in my test machine first.

Warning: Before you upgrade to PHP 5.4, make sure that you are not using any of the following packages, because they are not compatible with the PHP 5.4. Unfortunately, I don’t have a solution yet. Basically, I could not get them compiled.

  • eAccelerator: /usr/ports/www/eaccelerator/
  • PECL-TokyoTyrant: /usr/ports/databases/pecl-tokyo_tyrant/ (Updated: I just came up a solution here)

When I performed the upgrade using the following command:

sudo portsnap fetch update
sudo portmaster -Da

I got the following error message:

===>>> The databases/php5-sqlite port has been deleted: Removed from core php
===>>> Aborting update

The reason why you see this problem because php5-sqlite is no longer available in PHP 5.4. In order to solve this problem, you will need to delete the php5-sqlite extension.

cd /usr/ports/lang/php5-extensions
sudo make config

Uncheck the following: sqlite3 support

Now, deinstall this port. Yes, let’s remove it and install it again. (I’ve tried the reinstall option and it didn’t work, so let’s stick with deinstall and install.

sudo make deinstall clean install clean

Now let’s find out which php-SQLite we should delete:

pkg_info | grep php5-sqlite

In my case, I deleted this one:

sudo pkg_delete php5-sqlite-5.3.13

Now upgrade the port again and FreeBSD should be happy about it. Enjoy PHP 5.4.

–Derrick

Our sponsors:

[PHP]Fatal error: Allowed memory size of x bytes exhausted (tried to allocate y bytes)

Posted on by

A user complained to me that my PHP web applications stopped working today. After I digged into the error log, I found that following message:

PHP Fatal error:  Allowed memory size of 262144 bytes exhausted (tried to allocate 261900 bytes) in Unknown on line 0

Obviously, this is related to the memory error. Therefore I tried to increase the limit of memory_limit in php.ini. Since I have 8G of memory in my box, I think it is okay to set the memory limit of PHP to 4GB.

;memory_limit = 128M
memory_limit = 4096M

When I restart the Apache/PHP, I found another nightmare. My web application stopped working! When the user tries to access http://mywebsite/index.php, instead of rendering the code, the browser kept prompting the user to download the file.

After scratching my head for a while, I found that I missed something, which is very very important. I was running XAMPP (32-bit) on a Fedora 64-bit machine. See the problem? Since XAMPP is running in 32-bit, it does not understand what is 4096 MB. (If you install 4GB of memory in any Windows 32-bit machine, you will notice that Windows can only allocate 3GB of them, and the 1GB left memory is sitting inside your computer and doing nothing…) Therefore, I decrease the memory_limit to 2048MB, and that solved the problem.

Time to move away from XAMPP.

–Derrick

Our sponsors:

[PHP]imagecreatefrompng Error (After upgrading FreeBSD)

Posted on by

Today, I found that one of my PHP scripts stop working. After some investigations, I found that it was the function, imagecreatefrompng, which caused the problem.

Interestingly, other similar functions such as imagecreatefromgif and imagecreatefromjpeg were completely working fine. The program stopped working when calling imagecreatefrompng only.

Initially, I thought the problem was coming from the PHP side. Therefore, I tried to get the error messages as many as possible, such as PHP error (error_reporting), Apache error (error_log), and even system error (dmesg). Unfortunately, I couldn’t find anything.

The script was working completely fine until I upgraded the system. So I think the problem may come from a missing library. To give you some background, here is how imagecreatefrompng works. First, your program calls imagecreatefrompng, which involves the GD library. GD library calls a PNG function in your system (possibly libpng) to process the PNG file. Since the program comes with from the system library, PHP / Apache will not report anything about it.

Since it will be too complicated to identify which library caused the problem, I decide to reinstall all ports. It sounds a very long process but it wasn’t at all. It only took 20 minutes to finish the whole thing. So here is what I did:

#FreeBSD
#sudo portmaster -fa

After the installation is completed, I rebooted the machine and everything worked again!

Enjoy!

–Derrick

Our sponsors:

[FreeBSD]Problem to update PHP port

Posted on by

A new version of PHP (5.3.9) was available in FreeBSD today. Since it contained a lot of security fixes and enhancements, I decided to give it a try. After testing the new PHP in couple test servers, I think it is ready to upgrade the PHP on the production server. Oh well, I didn’t expect that I needed to spend my whole lunch break to trouble-shoot this problem. So here is what I did:

# cd /usr/ports/lang/php5
# make install
===>  Vulnerability check disabled, database not found
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for php5-5.3.9
===>  Extracting for php5-5.3.9
=> SHA256 Checksum mismatch for php-5.3.9.tar.bz2.
=> SHA256 Checksum OK for suhosin-patch-5.3.4-0.9.10.patch.gz.
===>  Refetch for 1 more times files: php-5.3.9.tar.bz2
===>  Vulnerability check disabled, database not found
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for php5-5.3.9
=> php-5.3.9.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch from http://dk.php.net/distributions/.
fetch: http://dk.php.net/distributions/php-5.3.9.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://de.php.net/distributions/.
fetch: http://de.php.net/distributions/php-5.3.9.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://es.php.net/distributions/.
fetch: http://es.php.net/distributions/php-5.3.9.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://fi.php.net/distributions/.
fetch: http://fi.php.net/distributions/php-5.3.9.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://fr.php.net/distributions/.
===>  Vulnerability check disabled, database not found
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for php5-5.3.9
=> SHA256 Checksum mismatch for php-5.3.9.tar.bz2.
=> SHA256 Checksum OK for  suhosin-patch-5.3.9-0.9.10.patch.gz
===>  Giving up on fetching files: php-5.3.9.tar.bz2
Make sure the Makefile and distinfo file (/usr/ports/lang/php5/distinfo)
are up to date.  If you are absolutely sure you want to override this
check, type "make NO_CHECKSUM=yes [other args]".
*** Error code 1

Stop in /usr/ports/lang/php5.
*** Error code 1

Stop in /usr/ports/lang/php5.
*** Error code 1

Stop in /usr/ports/lang/php5.

Initially, I thought it was a checksum error. So I decided to skip the checksum, i.e.,

#make install NO_CHECKSUM=yes

Unfortunately, it gave the same error. I think the problem might come from corrupted port files or port database. Instead of finding the source of the problem, I decided to rebuild the whole thing.

First, let’s remove the port database:

#sudo rm -Rf /var/db/portsnap/*

Next, we need to re-download all port files:

#sudo portsnap fetch extract

Some new ports may be released during the extraction, let’s make sure that the port tree is up to date:

#sudo portsnap fetch update

Now, we need to manually download the php source. Make sure that the file is stored in /usr/ports/distfiles/

#cd /usr/ports/distfiles/
#sudo wget http://fi.php.net/distributions/php-5.3.9.tar.bz2

Now, try to test whether the system can build php again. Notice that this will not install the PHP in your system.

cd /usr/ports/lang/php5
sudo make

If it gives no error, which means the PHP is ready to go. Now let’s clean up our work and make sure everything is ready.

sudo make clean

Notice that there is no way to upgrade the PHP from Make without uninstall it. Since it is a production server, I want to keep the website running. So I decide to let Portmaster to do all dirty works for me.

sudo portmaster -Da

Depending on your CPU, it may take 5 minutes to an hour to finish the update. Normally, the standard php package will work fine after the update. However, if it is not a standard package, such as PECL, you will need to do one more step. For example, here is the error messages right after I upgraded PHP:

#php -v
[eAccelerator] This build of "eAccelerator" was compiled for PHP version 5.3.8.
Rebuild it for your PHP version (5.3.9) or download precompiled binaries.

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20090626/memcache.so' - /usr/local/lib/php/20090626/memcache.so: Undefined symbol "php_session_create_id" in Unknown on line 0

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20090626/tokyo_tyrant.so' - /usr/local/lib/php/20090626/tokyo_tyrant.so: Undefined symbol "ps_globals" in Unknown on line 0

PHP 5.3.9 with Suhosin-Patch (cli) (built: Jan 12 2012 13:09:43)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

[eAccelerator] This build of “eAccelerator” was compiled for PHP version 5.3.8.
Rebuild it for your PHP version (5.3.9) or download precompiled binaries.

To solve this problem, simple rebuild the package, i.e.,

cd /usr/ports/www/eaccelerator
sudo make deinstall install clean

PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/20090626/memcache.so’ – /usr/local/lib/php/20090626/memcache.so: Undefined symbol “php_session_create_id” in Unknown on line 0

#cd /usr/ports/databases/pecl-memcache
#sudo make deinstall
#sudo make install clean

PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/20090626/tokyo_tyrant.so’ – /usr/local/lib/php/20090626/tokyo_tyrant.so: Undefined symbol “ps_globals” in Unknown on line 0

#cd /usr/ports/pecl-tokyo_tyrant
#sudo make deinstall
#sudo make install clean

After the re-installation is completed, make sure that PHP gives no complain:

#php -v

PHP 5.3.9 with Suhosin-Patch (cli) (built: Jan 12 2012 13:09:43)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

That’s it! Have fun.

Our sponsors:

Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’ (2)

Posted on by

When I tried to connect to the MySQL server through PHP, I got the following error: Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’ (2)

To give you some background, here is my situation. My Fedora Linux is a 64-bit machine, and I have installed a 32-bit version of XAMPP (i.e., 32-bit PHP, 32-bit MySQL) for the web server. Also, I have some PHP scripts that will be run in background. These scripts are run using 64-bit PHP. Both 32-bit and 64-bit PHP need to access the MySQL database. Long story short. I got the MySQL error message when I tried to execute using the 64-bit PHP, while the 32-bit PHP has no complain.

When PHP talks to MySQL, it needs to talk to the MySQL representative, i.e., mysql.sock. If it cannot talk to the mysql.sock, then PHP will be unable to access the MySQL database.

The reason why my 64-bit PHP could not talk to MySQL because of a wrong location of mysql.sock. To solve this problem, simply do the following:

First, let’s find out where is the PHP.ini of the 64-bit PHP:

sudo find / -name "php.ini"

In Fedora Linux, it is:

/etc/php.ini

Then, we need to find out where is the mysql.sock:

sudo find / -name "mysql.sock"

In my case, it is:

/opt/lampp/var/mysql/mysql.sock

Now, let’s tell PHP the location of the mysql.sock:

sudo nano /etc/php.ini

And change the following line from:

mysql.default_socket =

to:

mysql.default_socket = /opt/lampp/var/mysql/mysql.sock

Now, try to run your script again. The problem should be gone.

Have fun with MySQL.

–Derrick

Our sponsors: