pingle.org

Comments

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

Comment by Charlie — 2007/11/26 @ 5:54 pm

This script worked great!
Thank you.

Comment by Alexey Vdovin — 2008/03/21 @ 10:33 am

i got the same issue on my freebsd 7.0 , i got your fix script and now it`s running without problems, thank you!!

Comment by Esteban Galvan — 2008/06/05 @ 11:45 am

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

Comment by Octaviao Ionescu — 2008/06/25 @ 8:12 am

You saved my life! (and my sanity)
thanks.

Comment by patpro — 2008/09/05 @ 3:09 am

I’ve had the same problem that mysqli, but with sqlite.
spl seems to have to come before.

Comment by Geoffroy Desvernay — 2008/09/10 @ 11:03 pm

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

Comment by Valeri Matyukhin — 2008/09/18 @ 6:01 pm

Thank you so much for figuring this out!

Comment by Fred — 2008/09/24 @ 5:43 pm

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.

Comment by Edwin Culp — 2008/11/15 @ 12:05 pm

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

Thanks.

Comment by Tamas Horvath — 2008/11/29 @ 3:44 am

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

Comment by georgi iovchev — 2008/12/10 @ 5:30 am

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

Comment by Dmitriy Redchyts — 2009/01/16 @ 8:42 am

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.

Comment by KP — 2009/01/20 @ 4:46 pm

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!

Comment by yayix — 2009/03/30 @ 11:25 pm

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… :)

Comment by jim — 2009/03/30 @ 11:30 pm

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?

Comment by Barry Friedman — 2009/05/14 @ 2:35 pm

Thanks a zillion.
The re-ordering is my problem as well!

Comment by Mathos — 2009/05/17 @ 7:37 pm

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.

Comment by Octavian Ionescu — 2009/07/22 @ 4:35 am

I found that sybase_ct.so needs to be loaded last or else you will also have unknown core dumps. Scripts execute fine but it cores just like everything else mentioned.

Thanks!
Rusty Nejdl
http://networking.ringofsaturn.com

Comment by Rusty Nejdl — 2009/10/16 @ 12:40 pm

Jim,

Thanks for the script; it didn’t solve my problem, but it pushed me in the right direction.

I documented my steps here, for those who are interested: http://nerdstock.org/php_extensions

Cheers,
Rob

Comment by Rob — 2009/11/03 @ 12:10 pm

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

Thanks,
Nick

Comment by Nick — 2011/01/21 @ 8:11 pm

Thanks for the great Idea.

With the information on your and Rob’s site I hacked a new script together.
http://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh

Thanks,
olli

Comment by ohauer — 2011/04/03 @ 2:39 pm

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

Comment by Daniel — 2012/01/25 @ 2:51 pm

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.

Comment by chris — 2012/02/02 @ 9:21 am

Chris,

I had linked to that bit about recode in my original post ( http://www.pingle.org/2006/10/18/php-crashes-extensions ) but you are right, unless it’s really required, it’s probably best to just do away with recode entirely.

Jim

Comment by jim — 2012/02/02 @ 9:25 am

Comments

Leave a comment