PHP Crashes Caused By Extension Ordering: A Workaround

Posted on by

As I posted about nearly a year ago, I was (and still am) seeing Apache crashes caused by PHP extension ordering issues. So far, there has been no official or even unofficial workaround for the problem. I wrote a small shell script (/bin/sh for better portability) that will reorder the extensions in php.ini into the order that seems to cause the least problems for me.

Suggestions and improvements are more than welcome. I submitted this script to the PHP port maintainer for FreeBSD but have not yet heard back, which could be due to the hackishness of my script…

Anyhow, I’m pleased to announce that It Works For Me(TM) and you’re welcome to try it: fixphpextorder.sh

You may have to edit the file to correct pathnames and such, but if you build PHP from FreeBSD’s ports system, it should work. It’s especially nice when used with portupgrade like so:

portupgrade -A /root/bin/fixphpextorder.sh php5-\*

That will cause portupgrade to execute that script after each module is rebuilt. This will help if you have any cron or CLI PHP scripts that would reload modules while the upgrade is happening. I tried this method on several servers and it worked well. The only problem was a server running Cacti that polls every 5 minutes. I had two crashes while the upgrade was going on, but that is far better than the dozens it was getting when doing this by hand.

Update 11/21/07: I updated the script to also put pspell.so at the end of the file. It needs to be loaded after spl.so or PHP may crash Apache when a process terminates — either with a full shutdown or when an extra forked process is killed.

Update 6/25/08: Script updated to ensure spl.so comes before mysqli.so, which caused problems with PHP when used at the command line (CLI). Reported by Octaviao Ionescu.

Update 2/22/09: I updated the script again. I found that now sqlite.so must come after spl.so, or it complains about missing symbols. I also moved xml to the end hoping to fix another issue, but it did not help. It didn’t hurt, either, so I left the change in. Let me know if there are problems.

Update 1/21/10: Another script update. Had more crashes until I moved pdo/pdo_sqlite/pdo_mysql around a bit.

28 thoughts on “PHP Crashes Caused By Extension Ordering: A Workaround”

  1. This script worked great! I found your original post about this dumb problem some time ago, and I had to reference it again today, and happened to see the script and tried it out. Worked like a charm!

    cheers

  4. hi!

    i have had a problem on freebsd 7.0 with php 5.2.5 and 5.2.6 regarding mysqli extension. for apache module everything worked fine but for cli version it crashed with error regarding mysqli.so extension.
    after a little dig on the net i have found that mysqli depends on spl.so extension wich shall be loaded before the mysqli extension :

    extension=spl.so
    extension=mysqli.so

    after i have made it everything worked fine. if it helps for this script i’m glad if i was of any help

  7. I’ve added line:
    MV=/bin/mv
    and changed last line (MV instead CP):
    $MV $EXTENSIONS_INI.tmp $EXTENSIONS_INI
    The .tmp file disappeared.

  9. Jim, I just tried your script on a couple of machines and it is FANTASTIC, fixed both.

    This should definitely be integrated to ports for all php extensions.

    Thanks for your work, I was never able to figure out why the order was so important.

    ed

  10. Nice script, i have sqlite on my server and sqlite.so must be placed after spl.so.

    Thanks.

  11. I have tried this script on my test server … but it didnt help :(. I still got apache crash on apachectl restart. But not on every restart :))

    freebsd 7.0-stable (jul’08 world rebuilded); php 5.2.8; apache 2.0.63

  12. i have the same os and software
    problem of crash apache after apachectl restart gone after i write extension.ini in this order

    extension=gettext.so
    extension=iconv.so
    extension=ldap.so
    extension=mysql.so
    extension=pcre.so
    extension=session.so
    extension=xml.so
    extension=dom.so
    extension=pgsql.so
    extension=gd.so
    extension=zlib.so
    extension=curl.so

    maybe its help, sorry for bad english

  13. Thanks for your helpful post! Although the script didn’t eliminate the error messages, it gave me some ideas. I solved it by removing some modules.

  14. my original extensions.ini:
    extension=pgsql.so
    extension=pdf.so
    extension=ctype.so
    extension=simplexml.so
    extension=spl.so
    extension=dom.so
    extension=filter.so
    extension=hash.so
    extension=iconv.so
    extension=json.so
    extension=pdo.so
    extension=pdo_sqlite.so
    extension=posix.so
    extension=session.so
    extension=sqlite.so
    extension=tokenizer.so
    extension=xml.so
    extension=xmlreader.so
    extension=xmlwriter.so
    extension=zip.so
    extension=zlib.so

    after running fixphpextorder.sh:
    extension=pgsql.so
    extension=pdf.so
    extension=ctype.so
    extension=simplexml.so
    extension=dom.so
    extension=filter.so
    extension=hash.so
    extension=iconv.so
    extension=json.so
    extension=pdo.so
    extension=pdo_sqlite.so
    extension=posix.so
    extension=session.so
    extension=tokenizer.so
    extension=xmlreader.so
    extension=xmlwriter.so
    extension=zip.so
    extension=zlib.so
    extension=spl.so
    extension=sqlite.so
    extension=xml.so

    issuing “/usr/local/etc/rc.d/apache2 graceful” gives “Performing a graceful restart”

    but “/usr/local/etc/rc.d/apache2 status” says “apache2 is not running.”

    httpd-error.log shows:
    [notice] Graceful restart requested, doing restart
    [notice] seg fault or similar nasty error detected in the parent process
    [warn] pid file /var/run/httpd.pid overwritten — Unclean shutdown of previous Apache run?
    [notice] Apache/2.0.63 (FreeBSD) PHP/5.2.8 with Suhosin-Patch configured — resuming normal operations

    the output of the commands above is the same when i was using my original extensions.ini..

    FreeBSD 7.1-STABLE

    please help. TIA!

  15. If you just recently updated PHP on FreeBSD with the ports system, be sure to read /usr/ports/UPDATING, specifically the 20081211 entry. It is possible you have some extensions that are out of date with respect to the version of PHP you are running.

    I saw some errors until I followed the instructions in that entry, forcing an update of pcre (I actually had to rm /usr/local/lib/php/20060613/pcre.so before reinstalling).

    There are, unfortuantely, more ways to crash PHP than by extension ordering alone… :)

  16. I am still trying to solve this problem on one of my servers.

    I have tried using the extension reordering script and httpd still core dumps. The work around that I found, although quite unsatisfactory operationally, nevertheless works and it would be useful to find out why.

    I found that if I restart the running httpd using apachectl graceful httpd coredumps. However if I comment out the LoadModule php5_module and the AddModule mod_php5.c lines, httpd starts and I can then copy back the uncommented version of httpd.conf and do a graceful restart successfully.

    Another graceful restart then crashes httpd.

    I am running apache 1.3.41 and php5.2.9 on freebsd 7.0

    Any ideas?

  18. again i have now a problem with 5.2.10 version for cli.
    i have seen that mssql extension must come after dba extension, otherwise i get “Segmentation fault: 11 (core dumped)” after the script is executed.

  21. I somehow clobbered my extensions.ini, this helped me out tremendously!

    Thanks,
    Nick

  23. I had the same problem and tried the re-ordering script on 4 different FreeBSD machines that had the *same* configuration and it worked on some but not on others. Very confusing.

    Finally, the solution (for me) was that the extensions could be in any order whatsoever but I had to do a full apache stop + start to stop the segfaults; apache graceful or restart was simply not enough.

    WFM; YMMV

  24. Just thought I’d chip in with my findings – php-recode is the culprit in most cases, and has been for almost 10 years.

    It’s even documented:

    http://www.php.net/manual/en/recode.requirements.php
    http://www.php.net/manual/en/recode.installation.php

    I’ve been struggling with this since 2002 or so, and every time it is recode that causes problems. Removing recode fixes everything. And – when iconv and mbstring do the same thing (more or less), there’s really no reason to keep recode in the mix.

  26. Worked for me to solve an error installing pear (signal 11 issue)
    Thanks so much!

Leave a Reply

Your email address will not be published. Required fields are marked *

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image