I was thinking about that but a memory test came back clean. This system has several applications running on it; mysql (serving several databases), postfix, dns gallery2, samba, coppermine, etc. It's a busy little system :) And the only application that seems to be having a problem is mediawiki, everything else performs fine. The only change is updating the ports on the system which included an upgrade to PHP5 to the latest rev. Not sure how that plays into it as all of my other PHP applications are working fine. Anything else? I am willing to try anything to solve this..... Tim On 1/1/2007 7:40 PM, Kasimir Gabert wrote:

There aren't any extensions (that I know of) in the base distro that are enabled by default. You mentioned installing from ports - is MediaWiki being installed from the ports tree as well? Also, are you using any kind of PHP accelerator (like APC or eAccelerator) and if so does the problem still happen? I run MediaWiki on FreeBSD as well, and I haven't had any problems with it yet. However, my install is still using PHP 5.1.6 so if there is an issue with 5.2 I may just not have experienced it yet. The only other thing I can think of is some wacky dependency from the portupgrades that left some component in an unstable state. How did you perform the portupgrade? Did you use any of the automated tools or did you do them all by hand? I have seen the odd issue on fbsd with port upgrades going awry when done in the wrong order. Matt On 1/2/07, Tim Hogan <tim(a)hoganzoo.com> wrote:

Thank you Matt for pointing me in the right direction. Though I don't have a solution I do have a work around. To start with I do not run the ports version of mediawiki. I use the tar-ball distro from mediawiki's web site. I upgraded my system using the portupgrade tool and I too have see problems with the order that portupgrade compiles packages. In this case however the problem child turned out to be the new version of eAccelerator (v0.9.5). I have used eAccelerator for so long without any issues that I totally forgot about it. I tried to recompile eAccelerator after all of the other updates were complete and that mad no difference. It appears that there is some issue with mediawiki, php v5.2.0, and eAccelerator v.0.9.5. Seeing that none of my other php applications are having an issue I am guessing that there is a bug somewhere in mediawiki's script that checks to see if you are logged in or not. After out many different ideas my workaround ended up being to add the following in my .htaccess file in my mediawiki directory; php_value eaccelerator.filter "*.php !/data/webapps/mediawiki-1.8.2/includes/*.php" Not sure how that allows it to work as I still see mediawiki's php scripts being processed by eAccelerator, but it's working so I am not going to complain :) Thanks again Matt and thanks to everyone else who gave me another idea to try. Tim On 1/2/2007 8:04 AM, Matt wrote:

Thanks for the information. I now know where the real problem is and that there is a fix on the way. Tim On 1/3/2007 9:52 AM, Stefan Wahl wrote: