Hey guys,
I have had SMF for a few years. As faras I know it is the latest version.
Here is the problem. The server, Siteground, upgraded the server's PHP to the latest version and since then my forum has gone down multiple times. When I go to it, there is nothing but a blank screen. they restore it from the last time it worked... and it works for a week or so. Then randomly goes back t a blank screen. The Siteground technicians are getting tired of me and I am getting tired of having it down.
They say the version of PHP is 5.3. But the email I got said it was that it was being upgraded to 5.6? I thought SMF is a MySQL product? So how could a PHP upgrade effect SMF?
The MySQL version is 5.1.73
Here is a link to the site... http://incapp.org/smf/index.php?board=1.0
As you see it is a blank page. I can't get to the admin section or do anything.
Does anyone have this problem?
John Pepin
do you know what version of SMF was installed before the server upgrade?
SMF uses mysql yes, SMF is also coded in php so the php version is very important to keeping SMF running.
2 quick checks you should do:
* SMF version: open your index.php, you should see something like
$forum_version = 'SMF 2.0.10';
* PHP error log: check for a file called "error_log" or similar, or maybe check cPanel's logs (if you have cPanel). If everything else fails, ask your host. You should find several "fatal errors" that should allow us to understand why the blank page happens.
How do I open idex php?
I am in PHP MyAdmin...
you can open index.php in any text editor. you will find it in the main folder of your forum install.
you do not need phpmyadmin, which is used for your database.
I can acces my forum at all through the portal. The only access is through C Panel.
It looks like the SMF version I see in the database is, 2.0.10
Oh... I see. Through the files manager.
Yup it is 2.0.10
Here is a copy of the error log...
[13-Jul-2015 10:53:46 Etc/GMT+5] PHP Warning: Cannot modify header information - headers already sent in /home/incappor/public_html/smf/Sources/Errors.php on line 346
[22-Jul-2015 04:27:33 CST6CDT] PHP Warning: Module 'memcached' already loaded in Unknown on line 0
[22-Jul-2015 04:28:09 CST6CDT] PHP Warning: Module 'memcached' already loaded in Unknown on line 0
[22-Jul-2015 04:28:17 CST6CDT] PHP Warning: Module 'memcached' already loaded in Unknown on line 0
[22-Jul-2015 04:28:23 CST6CDT] PHP Warning: Module 'memcached' already loaded in Unknown on line 0
[22-Jul-2015 04:29:55 CST6CDT] PHP Warning: Module 'memcached' already loaded in Unknown on line 0
[23-Jul-2015 23:10:11 Etc/GMT+5] PHP Warning: Cannot modify header information - headers already sent in /home/incappor/public_html/smf/Sources/Errors.php on line 346
[25-Jul-2015 10:53:37 Etc/GMT+5] PHP Warning: Cannot modify header information - headers already sent in /home/incappor/public_html/smf/Sources/Errors.php on line 346
[26-Jul-2015 10:54:33 Etc/GMT+5] PHP Warning: Cannot modify header information - headers already sent in /home/incappor/public_html/smf/Sources/Errors.php on line 346
These warning are old, there should be something more recent which is causing the white pages...
Can you give us a phpinfo?
What is a phpinfo() file? (http://wiki.simplemachines.org/smf/What_is_a_phpinfo()_file)
When I try to access it I get:
The page you are trying to access is restricted due to a security rule.
If you believe the security rule is affecting the normal operation of your website, contact your host support team and provide detailed instructions how to recreate this error.
They will be able to assist you with rectifying the problem and adjusting the security configuration if needed.
I changed the permissions so it can execute/world and still get the message.
It saved as phpifo.php.txt however. Is that effecting it?
You get that when accessing the phpinfo page? :o
You need to talk to your host then... They misconfigured something, methinks. Ask them what's this "security rule". The server logs should tell them what, but you don't have access to those ;)
Looks like they put phpinfo in "disable_functions" section of php.ini. ;)
Which is rather useless. Would ask 'em to remove it indeed or create an exception for you with a custom php.ini.
I tried instant chat but he doesn't have access, so I put in a support ticket.
"Looks like they put phpinfo in "disable_functions" section of php.ini. ;)
Which is rather useless."
Could that be why I only get a blank screen when I try to access my forum?
Got it. It was my fault for misnaming the file.
Holy moly! It is a huge amount of stuff!
What am I looking for?
Here is a link; http://incapp.org/smf/phpinfo.php
Everything looks normal there...
In index.php you can find this:
error_reporting(defined('E_STRICT') ? E_ALL | E_STRICT : E_ALL);
Make it just
error_reporting(E_ALL);
See if something pops up. Also, add
$db_show_debug = true;
To the end of Settings.php (a line before the final "?>")
Quote from: numapepi on July 29, 2015, 02:22:20 PM
Could that be why I only get a blank screen when I try to access my forum?
No.
What could be though; I noticed they're running FCGI in their system; so either running mod_fcgid or mod_ruid2 if this is a cPanel server.
Incorrectly chmod'ing your files (or them not applying the proper ownership (chown) to your files) may cause issues, and that may not show up in the error_log that you can see; only in the hosts primary log file.
This may have happened if they upgraded and they didn't run FCGI previously.
Anyway, pls follow margarett's instructions. :)
99% sure this is a ownership or permission issue as Liroy said.
http://wiki.simplemachines.org/smf/Chmod
Okay I did what Margaret said, "Everything looks normal there...
In index.php you can find this:
Code: [Select]
error_reporting(defined('E_STRICT') ? E_ALL | E_STRICT : E_ALL);
Make it just
Code: [Select]
error_reporting(E_ALL);
See if something pops up. Also, add
Code: [Select]
$db_show_debug = true;
To the end of Settings.php (a line before the final "?>")"
I replaced the line in index.php and added the code to settings.php.
Still a blank screen.
Here is a link to the site to see for yourself.
http://incapp.org/smf/index.php?board=1.0
BTW thank you so very much for the time and help so far!
John
Also add this at the top of index.php. This will force PHP to display the errors instead of hiding them:
ini_set('display_errors', 1);
done.
It's really weird that it's not displaying any errors at all even after all that. Are there any recent PHP-related errors in the server error log?
Do check the permissions indeed, or simply ask the host to have a look in their error log. They can see more. :)
The Siteground support team kind of repaired my forum...
Hello John,
Thank you for contacting our Help Desk.
I have straced the system call made by the execution of the index file of your application and it showed that the data loaded was from the cache folder of your application.
Therefore I have renamed the cache folder to cacheOLD which has basically flushed the cache and the issue appears to have been resolved.
If you have any further questions, do not hesitate to contact us again.
Best Regards,
Dimitar Dimov
Technical Support Team
So it would seem that the cache was the root of the problem?
However the forum now has an error message that the cache is not available and will negatively effect my forum...
Any ideas?
you need a cache directory.... he should have just deleted the cache*.* files out of that directory rather than renaming the whole thing
There is a cache directory.
He deleted the cache and it solved the problem. But this problem seems to reappear. I can't log in as admin when the problem happens however.
I could fo through C Panel and delete a file or edit a text file... But that still won't solve the macro issue...
That is a progress.
Can you check the permissions of the cache directory itself, as well as the files inside it?
It looks like th permissions for the files in that directory are:
User Group World
Read X X X
Write X 0 0
Execute 0 0 0
Is that what you wanted?
644, that's fine.
What about the files inside?
Quote from: margarett on July 31, 2015, 11:28:08 AM
644, that's fine.
What about the files inside?
644 on files is what was posted.
Quote from: numapepi on July 31, 2015, 11:16:43 AM
It looks like th permissions for the files in that directory are:
so then you want to know the chmod on the folder not the files?
Ups :P
Yeah, what are the permissions on the "cache" folder itself?
And is the forum running now?
The cache folder itself is 755.
The forum is running for now.
OK, let's keep our bets in the permissions issue in the folder or the files inside.
If it crashes again (which is expected to happen, according to your recent past :( ) please check the permissions of the folder and all files inside, then delete all files (which should bring it back to life)
Are you suggesting the permissions could change?
When SMF creates a file (cache files are created by SMF) it tries several permission levels until it eventually reaches 777, this being the "last resort".
My guess at this point is that, for some reason (usually ownership issues) it finds the need to reach 777 on any given file and that your server kills the script because of having a file with these permissions.
That being said: can you try to chmod your index.php to 777 and see if the white screen returns? Then chmod it back to 644 and check if it lives again?
I changed the cache folder to 777... it worked fine. I also changed all the cache files to 777 and it still worked. Then I changed them back.
I guess I didn't read the post correctly. I noticed it said index.php and not cache. I changed the index.php to 777 and it hosed up the forum, but differently than the white screen. The error was "error code 500...
If you are the webmaster of this site please log in to Cpanel and check the Error Logs. You will find the exact reason for this error there.
Common reasons for this error are:
Incorrect file/directory permissions: Above 755.
In order files to be processed by the webserver, their permissions have to be equal or below 755. You can update file permissions with a FTP client or through cPanel's File Manager.
Incorrect Apache directives inside .htaccess file.
Make sure you have not specified unsupported directives inside the local .htaccess file. Such include PHP settings and Apache module settings."
I changed the index back and it works again.
Dang...
I'm now officially lost. Your tests (thank you) totally got me lost.
So, cache folder, the original culprit, seems to be permissions-tolerant. While index.php throws a perfectly visible 500 error (expected). So my theory was just flushed :P
Could the subprogram somehow be caching a corrupted file? Is PHP somehow involved with the cache process? Could the new version cause a cache file to be corrupted?
No idea. It would be nice if your host tell us what's going on in the logs, really...
As of now, we can only guess :(
The server preventing .php files with permission 777 to execute is completely normal, it's a security mechanism.
777 should be avoided unless needed. So setting things like Settings.php and the cache folder to 777 is fine and dandy (though preferably 755 if it'll accept that), and that should keep the forum running just fine; but keep index.php lower than 777 with a max of 755. (And that's, imho, already too high) If the cache folder is 777 and that starts causing issues, that is... vague.
Okay... it's happening again.
http://incapp.org/smf/index.php?board=1.0
The permissions for the Cache folder is 755.
The permissions for the files withing the folder are 644.
It seems to happen on Wednesdays for whatever reason as well.
Here is the code in the last two cache files just before the page went blank...
"<?php if (!defined('SMF')) die; if (1438815058 < time()) $expired = true; else{$expired = false; $value = 'a:20:{s:2:"id";i:1;s:10:"moderators";a:0:{}s:3:"cat";a:2:{s:2:"id";s:1:"1";s:4:"name";s:16:"General Category";}s:4:"name";s:18:"General Discussion";s:11:"description";s:62:"Feel free to talk about anything and everything in this board.";s:10:"num_topics";s:3:"630";s:17:"unapproved_topics";s:1:"0";s:16:"unapproved_posts";s:1:"0";s:22:"unapproved_user_topics";i:0;s:13:"parent_boards";a:0:{}s:6:"parent";s:1:"0";s:11:"child_level";s:1:"0";s:5:"theme";s:1:"0";s:14:"override_theme";b:0;s:7:"profile";s:1:"1";s:8:"redirect";s:0:"";s:11:"posts_count";b:1;s:18:"cur_topic_approved";b:1;s:17:"cur_topic_starter";i:0;s:6:"groups";a:2:{i:0;s:2:"-1";i:1;s:1:"0";}}';}?>"
"<?php if (!defined('SMF')) die; if (1438815526 < time()) $expired = true; else{$expired = false; $value = 'a:0:{}';}?>"
go ahead and DELETE all of the files in the cache directory, other than index.php and the htaccess file
Since it seems to happen regularly, I wonder if it might be some automated script on the host side which is doing something on Wednesdays....
I went to go delete them and discovered there is no index or htaacces files? Could that cause the problem?
I deleted them all, (trying just the newest two first, but that didn't fix the problem) and it cleared up the problem. The forum is working now.
well, the directory SHOULD have at least an index file, protecting it fro direct access. grab the file from the upgrade or install archive.
Okay... I moved the index and htaccess fro the cache.b file the tech support made.
It's back. I could just delete the cache and get it working but I would REALLY like to solve it. Besides, someone else might have this problem down the road...
Could you ask your host how did they trace the problem to the cache folder before?
Please ask your host what kind of limits they place on anything I/O related. From file limits/file per folder to simultaneous writes: whatever.
Something is corrupting over and over again, or so it would seem. (Or something odd happens with access to it. The problem is: you can't really see any error, you can only properly see it in the full server error log; which only the host can access... I'd love to see what entries your site produces in that error log :))
On the cache settings page in SMF, what does it say the server has installed?
I'd also like to know:
- What are the permissions/ownership of the files in the cache folder, and what are they for your other files (just pick a few random ones, like index.php)?
- Which mods are you using, if any?
It smells like a server issue, but can't shoot it down just like that.
Here is the response...
Hello John,
Thank you for contacting our Help Desk.
I have reviewed your previous tickets and I noticed that my colleague used strace to troubleshoot the issue.
Then he have set the cache folder permissions to 755 which are the default permissions for the folders.
I have checked the Apache and I am not able to find any error on your account except the ones below.
Code:
[Tue Aug 18 07:15:15 2015] [error] [client 93.172.8.247] script not found or unable to stat: /home/incappor/public_html/yabb/yabb.pl, referer: http://incapp.org/yabb/yabb.pl
[Tue Aug 18 07:15:17 2015] [error] [client 93.172.8.247] script not found or unable to stat: /home/incappor/public_html/yabb/yabb.pl, referer: http://incapp.org/yabb/yabb.pl
[Tue Aug 18 07:15:17 2015] [error] [client 93.172.8.247] script not found or unable to stat: /home/incappor/public_html/yabb.pl, referer: http://incapp.org/yabb.pl
[Tue Aug 18 07:15:17 2015] [error] [client 93.172.8.247] script not found or unable to stat: /home/incappor/public_html/yabb/yabb.pl, referer: http://incapp.org/yabb/yabb.pl
[Tue Aug 18 07:15:18 2015] [error] [client 93.172.8.247] script not found or unable to stat: /home/incappor/public_html/yabb.pl, referer: http://incapp.org/yabb.pl
[Tue Aug 18 07:15:18 2015] [error] [client 93.172.8.247] script not found or unable to stat: /home/incappor/public_html/yabb/yabb.pl, referer: http://incapp.org/yabb/yabb.pl
[Tue Aug 18 07:15:19 2015] [error] [client 93.172.8.247] script not found or unable to stat: /home/incappor/public_html/yabb.pl, referer: http://incapp.org/yabb.pl
[Tue Aug 18 08:06:10 2015] [error] [client 93.172.8.247] client denied by server configuration: /home/ajile/public_html/forum2/index.php, referer: http://www.ajile.com/forum2/index.php
[Tue Aug 18 08:06:13 2015] [error] [client 93.172.8.247] client denied by server configuration: /home/ajile/public_html/forum2/, referer: http://www.ajile.com/forum2/
The permissions are 755 and the owner of the folder is *******, which is your cPanel user name, so currently there is no issue with it.
As for the mods, I am not able to provide you with this information since I am not the website administrator and I cannot see this information.
I hope that you will find this information useful and if you need any other assistance, please contact us again.
Best Regards,
Nikolay Hadzhiyski
Customer Service Department
By mods I meant the modifications you installed on SMF. :) Like with the package manager.
How about their resource limits on I/O? Also, is the folder in the group of your user as well; or is it in the group nobody?
You should actually be able see the details of ownership/permissions in your FTP client, no need to ask support.
I'm guessing the logs rotated btw.
The only mod I have installed is "Stop Spammer." But I removed it because it made it cumbersome to upgrade to the latest version.
Everything is in the folder SMF within the public folder.
I don't know how to look at the IO resource limits...
Why would having a mod make it cumbersome to upgrade? I have 20 mods and can upgrade between minor versions in seconds.
Stop spammer had to be disabled before I could auto upgrade. Else I had to download it and manually install it.
Untrue.... Unless you are using one of those silly host-side autoinstallers/upgraders.
We recommend never using those and handling yourninstallao and upgrades clearly through the admin interface.
Again... I have 20 mods, including stop spammer and I never had to uninstall it or even disable it.
Quote from: numapepi on August 18, 2015, 04:46:31 PM
I don't know how to look at the IO resource limits...
That was something you *do* have to ask support :)
Here is the response...
Hello John,
Thank you for contacting our Help Desk.
Since your account is hosted in a shared hosting environment, there are limits applied in order to provide fair share of the server's resources. The exact quotas on your account are as follows:
Code:
CPU executions per month: 300 000
Disk Usage: 20GB
Inode Usage: 300 000
Simultaneous Processes: 20
Database Size: 750MB
Email Quota: 1000MB
I am not at those limits yet. Moreover, why would they effect a cache issue?
I would suggest you ask them for the logs as soon as the problem occurs. We need to know what causes the error and only the server logs can tell us that...
the issue would seem to be with this one...
client denied by server configuration
why would your host/server be denying the client connection?
Hopefully a more detailed log of the actual even will show us something... but this really does sound like a host configuration issue
I believe it is a host configuration issue as well. The problem only started when my host upgraded their PHP version.
Oh well... I'll delete the cache and get it working. Next time I'll ask for the logs the moment I notice it.
Talk to you all later!
Thanks!
My SMF went back down. I deleted the most recent cache files and it came back up. What is different is that I didn't need to delete them all this time. I sent a support ticket in the moment I noticed it to get the error report.
Okay, the support people said, "The only errors in the error log for your application are for too many connections from one IP address, the same ones that my colleague mentioned in his previous reply."
Could 1 ip crash my SMF by hitting it too many times???
not if the host is configured correctly...
that is a silly statement
Maybe try it at another host.
I don't think I can give you any advice other than that anymore, we've tried everything but the issue keeps appearing to be boiling down to the configurations/setup of your hosting provider; which makes their servers do something abnormal.
If they can't fix that, then the only option is to look in to switching to a properly configured host.
Or you could try other software, but chances are the issue may (eventually) occur there as well as soon as you start using (file)caches.