I help manage a couple of sites installed with PN 0.75 and spliced together in a Multisites-style hack, and they share about 30% of the PN tables. Magically last week I received a call that one of the sites started producing a blank white page [22] with the message: "Session initialisation failed [23]" The other site was still working perfectly, and they run on the same hardware.

I did some forum searches here, and it seems to be an error others have experienced too, and not always with a successful fix. With so many shared resources between the sites, it was not that hard to track it down. Today I did some troubleshooting with my co-manager for the sites and we did successfully isolate and solve the problem. We ignored all the shared tables and files, and concentrated on only those unique to each site.

What finally turned up was a problem with the session_info table. A global ANALYZE TABLE SQL query run across all the suspect tables was unable to examine session_info. Trying to browse that table in phpMyAdmin [24] also failed. All of the other tables were fine. I confess we didn't try to do a repair on it; the data was not important to us, and we'd wait long enough as it was to start looking at the problem. Instead we did a quick backup of the table files, and then we overwrote all three of the session_info files (.MDY, .MYI, and .frm) with the similar copies from the sister website. Copying over the bad/corrupted table information fixed it and the site was back up instantly. (Overwriting individual files did not work; only when all three were done did it fix it).

So if you're getting this error too, try taking a look at your session_info table and see if it can be opened for reading. Now why the table became inaccessible is a different question. It may not be related, but I know the site that went down has a history of being hacked (prior to the PN install it now runs). My only speculation is that perhaps an attempt to hack the site resulted in bad data being sent to the session table. Not being a site hacker myself, I don't really know, but for now the site's running fine again.

I hope this can help you others getting this site-killing error message. :)
--Kevin

Thanks for the great walkthrough Kevin. I've moved it over to the Tutorials and Solutions area.

There's also some additional information in a thread [35] I posted a while back.

-Mark

kjhatch and markwest, thank you a million. i havent yet attempted this fix but this is great information. I have been haveing this problem alot lately and it has driven me mad. I couldnt find anything on the subject until today. Myself and my tech will be attemtping to fix this problem on our site now. we are running phpbb2 however, should this work for that particluar format as well?

My tech and myself have tried both of the suggested methods to correct the Session Initialasation Failed problem with absolutley NO LUCK. We are litterally at our wits end. I have a succesfull website but my members are becoming very aggitated at this problem. I would be more than happy to hire someone here to fix this problem permanently if possible. Or if preferred I will donate to your work on PN markwest, I just really need this problem taken care of asap. Can anyone here help please?

You have tried repairing the table, and also dropping and recreating it?

--
Regards,
Simon

itbegins.co.uk - Zikula Consulting [51]

Please read the Support Guide [52]

Yes, my tech assures me he has done both of these!

I can temporarily allow you admin access if needed, I just have to somehow get this taken care of.

I can take a look if you really need - I'd need access to phpMyAdmin [63], FTP and PostNuke administration...

You'd be better off sorting it yourself so you can fix it should the problem arise again

--
Regards,
Simon

itbegins.co.uk - Zikula Consulting [64]

Please read the Support Guide [65]

We have been beating ourselves to death trying to figure it out with no luck. We will keep trying a while longer but if you dont mind I may take you up on that! Is it ok to pm you if I decide to let you in to have a look?

That's fine.

--
Regards,
Simon

itbegins.co.uk - Zikula Consulting [76]

Please read the Support Guide [77]

OK,I have been trying to solve this problem for quite a while now and all above solutions haven't help.
If you have tried the above and still get the problem,go check your php.ini file and check the "session.autostart" variable.
This variable should be off.
Let me explain exactly a way to solve this.
First of all you have to view your PHP info.
A way to do this is by uploading the PostNuke Swiss Army Knife [83] (psak102 you can find it in the PostNuke downloads in this site),navigate to the file through your browser and click on the view PHP info link.Search a bit in the resulting page and you will eventually find the variable saying "session.autostart".
If this variable is ON then keep reading,else I have no other way to help you
First of all try to contact your hosting provider and ask him to change the variable to OFF.
If he can't then ask him the way to change it by yourself.
I changed it by editing the .htaccess file in my root directory.
To do that, add below the "Options FollowSymLinks" line the following

and reupload the .htaccess file.
This and all the above solutions should eventually correct the problem I believe.

The fixes that were posted in markwest's thread were all I needed to fix the problem. Just dropped and recreated the table as per instructed, and everything immediately started running perfectly again.

Apparently, someone poked the site the wrong way...

To: Joshoua

Thanks for your post. After a couple of weeks of trying reinstalling my site etc.. , your post helped me solve the problem. I had tries all others and got a little desparate.

Markwest's details of dropping the table and recreating it (found here: http://forums.postnuke.com/index.php?name=PNphpBB2 [99]&file=viewtopic&t=9316 ) has worked every time I have run into this on my site over the past few months.

Just last week I upgraded from .726 to .750 (the only change on the server/website) and now I have had this happen almost everyday since then.

Dropping and recreating the table fixes the issue...site is back up and you have to log back in (because the session info is all gone). But this is obviously only a temp fix. It has happened probably a total of 10-12 times for me since march. 5 of which were in the last 5-6 days.

So...either there is some problem with the code that is not cleaning up the table info correctly and it gets bloated/corrupted (which I doubt since it has happened to me about once a day and I don't get gigs of traffic a day). Or there is a coincidental hack attempt that is ongoing. Of which I wouldn't know where to start.

And if so...it would be nice to figure out a way to update the code of PostNuke or mysql/php to prevent the hack.

Query limits mentioend before might be a good thing to check for, but since how to do that wasn't explicitly posted in either this thread or the other...I will have to go look up how to check for that.

The suggestion to check the php.ini for the session.auto_start....mine was set to zero (which I take to be off as suggested).

I run my site www.webwarrior.net on a FreeBSD 4.11 box
Apache/1.3.31
with:
Max Requests Per Child: 0 - Keep Alive: on - Max Per Connection: 100
Timeouts Connection: 300 - Keep-Alive: 15

PHP/4.3.7
MySQL 3.23.58

------------
And I just looked up the latest version numbers as of today..they are as follows:

PHP 4.4.0 just was releast July 11th
mysql 4.1.12
Apache 1.3.33

so I will look into upgrading those and see if that helps.

--
Tragen

http://www.webwarrior.net

"SPOON!"..."There is no spoon"

Well this happened to me today and I was able to repair the DB. I honestly think it was a attempted hack because I have noticed the past couple of days a huge increase in site hits without site activity. This was also limited to just one hour out of the day....

http://www.dnaracing.net/modules.php?op=modload&name=Stats&file=index

If it was a hack how do I prevent this or find out how they are attempting to hack?