URGENT: Startpage disappears - white and blank

249 Posts

cyclissmo Reply #51, 15 years, 7 months ago

Quote from: mindeffects at Feb 08, 2011, 07:32 AM

Another blank screen. Damn. My idea: "domain.com" and "www.domain.com" should not lead to the same page. The cahche dislikes that. I changed my ".htacces" to redirect (301) all "http://domain.com" to "http://www.domain.com". Hopefuly that helps. My head is close to being chopped off...

Well I suppose that rules out the separate error pages as a possible cause/solution embarrassed

I don’t see how the non-canonical domain should affect caching, but it wouldn’t hurt to try normalizing it to www, at least for SEO purposes.

Can you post your access logs when the site went down, even if it’s the same as last? I’m going to set up a test environment to help us track this thing down.

lo9on.com

MODx Evolution/Revolution | Remote Desktop Training | Development

☆ A M B ☆
179 Posts

mindeffects Reply #52, 15 years, 7 months ago

Quote from: cyclissmo at Feb 08, 2011, 01:41 PM

Well I suppose that rules out the separate error pages as a possible cause/solution

Ryan and Jason of MODx strongly recommend the use of separate start, error and unauthorized pages. Perhaps we are dealing with one or more things happening together and causing that mess. Therefore they can be a part of the problem.

Quote from: cyclissmo at Feb 08, 2011, 01:41 PM

I don’t see how the non-canonical domain should affect caching, but it wouldn’t hurt to try normalizing it to www, at least for SEO purposes.

Won’t hurt, yes, and somehoe this double fire (with and without www) is allways happening near each crash. So I took care of that by activating the redirection part in side the standard MODx htaccess by removing some "#"s.

Quote from: cyclissmo at Feb 08, 2011, 01:41 PM

Can you post your access logs when the site went down, even if it’s the same as last? I’m going to set up a test environment to help us track this thing down.

Sure. Today I also fired dozends of curl batches agains the server but none had an effect. Somehow these Bots have some special powers.
You can see that at 07:42:04 the data amount of the startpage "/" dropped from 9826 (9839) byte to 435 byte and less. Just as if the Bot killed the website.

  212.95.54.167 - - [08/Feb/2011:03:42:45+0100]  GET / HTTP/1.0           200 9753 - Mozilla/4.0 (compatible; MSIE 6.0; Update a; AOL 6.0; Windows 98)          www.domain.com
 208.177.72.199 - - [08/Feb/2011:03:46:18+0100]  GET / HTTP/1.0           200 9753 - Mozilla/4.0 (compatible; MSIE 6.0; Windows XP)                             www.domain.com
 87.250.252.241 - - [08/Feb/2011:05:21:37+0100]  GET / HTTP/1.1           200 9831 - Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)           www.domain.com
  66.249.72.122 - - [08/Feb/2011:05:35:38+0100]  GET /robots.txt HTTP/1.1 200  344 - Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)   www.domain.com
  119.63.196.33 - - [08/Feb/2011:06:24:49+0100]  GET /robots.txt HTTP/1.1 200  307 - Baiduspider+(+http://www.baidu.com/search/spider.htm)                      www.domain.com
 95.108.150.235 - - [08/Feb/2011:07:42:02+0100]  GET /robots.txt HTTP/1.1 200  344 - Mozilla/5.0 (compatible; YandexBot/3.0; MirrorDetector; +http://yandex.... www.domain.com
 95.108.150.235 - - [08/Feb/2011:07:42:02+0100]  GET /robots.txt HTTP/1.1 200  344 - Mozilla/5.0 (compatible; YandexBot/3.0; MirrorDetector; +http://yandex.... domain.com
 95.108.150.235 - - [08/Feb/2011:07:42:03+0100]  GET / HTTP/1.1           200 9830 - Mozilla/5.0 (compatible; YandexBot/3.0; MirrorDetector; +http://yandex.... www.domain.com
 95.108.150.235 - - [08/Feb/2011:07:42:03+0100]  GET / HTTP/1.1           200 9826 - Mozilla/5.0 (compatible; YandexBot/3.0; MirrorDetector; +http://yandex.... domain.com
 95.108.150.235 - - [08/Feb/2011:07:42:04+0100]  GET / HTTP/1.1           200  435 - Mozilla/5.0 (compatible; YandexBot/3.0; MirrorDetector; +http://yandex.... www.domain.com
 95.108.150.235 - - [08/Feb/2011:07:42:04+0100]  GET / HTTP/1.1           200  435 - Mozilla/5.0 (compatible; YandexBot/3.0; MirrorDetector; +http://yandex.... domain.com
 95.108.150.235 - - [08/Feb/2011:07:42:05+0100]  GET /robots.txt HTTP/1.1 301  573 - Mozilla/5.0 (compatible; YandexBot/3.0; MirrorDetector; +http://yandex.... domain-redirect.com
 95.108.150.235 - - [08/Feb/2011:07:42:06+0100]  GET / HTTP/1.1           301  553 - Mozilla/5.0 (compatible; YandexBot/3.0; MirrorDetector; +http://yandex.... domain-redirect.com
   91.23.130.90 - - [08/Feb/2011:08:46:54+0100]  GET / HTTP/1.1           200  436 - Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100722... www.domain.com
   91.23.130.90 - - [08/Feb/2011:08:47:56+0100]  GET / HTTP/1.1           200  339 - Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100722... www.domain.com
   91.23.130.90 - - [08/Feb/2011:08:48:00+0100]  GET / HTTP/1.1           200  338 - Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100722... www.domain.com
   91.23.130.90 - - [08/Feb/2011:08:48:13+0100]  GET / HTTP/1.1           200  436 - Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100722... domain.com
   91.23.130.90 - - [08/Feb/2011:08:48:21+0100]  GET / HTTP/1.1           200  339 - Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100722... www.domain.com
   91.23.130.90 - - [08/Feb/2011:08:48:39+0100]  GET / HTTP/1.1           200  339 - Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100722... www.domain.com
220.181.108.121 - - [08/Feb/2011:09:15:01+0100]  GET / HTTP/1.1           200  399 - Baiduspider+(+http://www.baidu.com/search/spider.htm)                      www.domain.com 
 212.243.229.90 - - [08/Feb/2011:09:15:21+0100]  GET / HTTP/1.1           200  339 - Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/2010120... www.domain.com
 195.95.146.172 - - [08/Feb/2011:10:09:05+0100]  GET / HTTP/1.1           200  436 - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; WOW64; Trident/4.0; ... www.domain.com
 195.95.146.172 - - [08/Feb/2011:10:09:14+0100]  GET / HTTP/1.1           200  339 - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; WOW64; Trident/4.0; ... www.domain.com
   193.18.239.4 - - [08/Feb/2011:10:09:34+0100]  GET / HTTP/1.1           200  436 - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CL... www.domain.com
 195.95.146.172 - - [08/Feb/2011:10:09:37+0100]  GET / HTTP/1.1           200  339 - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; WOW64; Trident/4.0; ... www.domain.com
 195.95.146.172 - - [08/Feb/2011:10:09:43+0100]  GET / HTTP/1.1           200  436 - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.6;... www.domain.com
   207.46.13.98 - - [08/Feb/2011:10:25:39+0100]  GET /robots.txt HTTP/1.1 200  344 - Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)... www.domain.com
   207.46.13.98 - - [08/Feb/2011:10:26:33+0100]  GET / HTTP/1.1           200  436 - Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)... www.domain.com
   92.196.38.29 - - [08/Feb/2011:10:34:00+0100]  GET / HTTP/1.1           200  339 - Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.9 (KHTM... domain.com

Does this seem familiar to you?

MINDEFFECTS – DESIGN for PRINT, WEB and MEDIA
http://twitter.com/mindeffects · http://www.facebook.com/mindeffects · http://www.youtube.com/mindeffects/ · skype://mindeffects_oliver

249 Posts

cyclissmo Reply #53, 15 years, 7 months ago

Quote from: mindeffects at Feb 08, 2011, 03:59 PM

Does this seem familiar to you?

Very familiar.

I’m wondering if it’s just coincidence that our sites seem to have been affected by the same bot. Yandex bots have a fairly bad reputation for sucking up bandwidth and disregarding robots directives, although that in itself should not cause a site to fail.

lo9on.com

MODx Evolution/Revolution | Remote Desktop Training | Development

159 Posts

gOmp Reply #54, 15 years, 7 months ago

didn’t expirenced a blank in a while, but as i remember i had bad requests from bots (robotos.txt and such) as well as both of you.

very odd.

Michael Shraibman( gOmp) | Freelance Design & Development | wink

impossible ~~is nothing~~...

249 Posts

cyclissmo Reply #55, 15 years, 7 months ago

Well, a little progress.

I am able to reproduce the blank page on a regular basis now, using multiple concurrent requests to the index page. Here’s the conditions:

1. When alternating between non-canonical domains: www.domain.com, domain.com, www.domain.com, ...
2. With dedicated error, unauthorized, unavailable pages. The state of these settings seems to have no effect with my tests.

I made snapshots of the database and cache directory immediately before and after the white screen of death.

The only differences with my database snapshots were some mod_session records. Everything else is identical.

I saw no differences within the cache directory contents.

Looks like a possible temporary fix is canonicalizing the domain to www.* for now. Looks like your fix just might do the trick, mindeffects.

Mike

lo9on.com

MODx Evolution/Revolution | Remote Desktop Training | Development

MODX Staff
12,272 Posts

Ryan Thrash Reply #56, 15 years, 7 months ago

You should definitely always pick http://example.com or http://www.example.com for your domains. Always. Likewise you should always have dedicated error/unauthorized pages that are not site start. These configuration "recommendations" cannot be reiterated enough.

When it comes to shared hosts and bots, all bets are off. Heck it can even be a problem on non-shared hosts. Case in point we had to deny all the IPs associated with the MSN/Bing spider a year or so ago as it was crushing our 16GB RAM 8-cores of Xeon server. We didn’t have a blank cached page, but we definitely had problems. The reason it’s magnified on shared servers is they tend to be over-provisioned in the first place, and a web-spider can hit multiple sites on the shared server at the same time, saturating it’s IO and causing massive problems where things just don’t respond and die.

Mike: would love to know more about how you were able to reproduce the problem. Please post in the bug here: http://bugs.modx.com/issues/3111 (We are actually working on some caching refactoring and it would make for a good test case.)

Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me

☆ A M B ☆
179 Posts

mindeffects Reply #57, 15 years, 7 months ago

Quote from: cyclissmo at Feb 08, 2011, 06:02 PM

I am able to reproduce the blank page on a regular basis now, using multiple concurrent requests to the index page. Here’s the conditions:
1. When alternating between non-canonical domains: www.domain.com, domain.com, www.domain.com, ...

I am not able to reproduce the blank screen.
I used this shell shript:

# make mutiple website-calls
blankit()
{
for ((i=0; i < $TURNS; i++)) ; do
	curl --silent http://www.$1 > /dev/null &
	curl --silent http://$1 > /dev/null 
done
}

echo "Start"

# Basic definitions
DOMAIN="domain.com"
TURNS=16

# marker entry for logfile
curl --silent http://www.$DOMAIN/_____START_______________.html > /dev/null

# test 1
FILE="robots.txt"
blankit $DOMAIN/$FILE 

# test 2
FILE=""
blankit $DOMAIN/$FILE

echo "Done"

@Mike: How did you manage to "blank" you website?

Oliver

MINDEFFECTS – DESIGN for PRINT, WEB and MEDIA
http://twitter.com/mindeffects · http://www.facebook.com/mindeffects · http://www.youtube.com/mindeffects/ · skype://mindeffects_oliver

5 Posts

zero_two Reply #58, 15 years, 7 months ago

Just a short comment... I’m dealing with the same problem - blank page.
At the moment still using MODx Revolution 2.0.4-pl2.
I implemented the tips (robots and additional resources for error pages).
I hope the changes will do their thing and get my client of my back again wink

If not, i’ll post my experiences here again..

Thanks

6 Posts

greex Reply #59, 15 years, 7 months ago

Hello,

I’m sorry but I think I have/had the same issue here an I’m very lucky that I found this thread last night.

System:
ModX Revo 2.0.7-pl
Ubuntu 10.04, apache2, Plesk 10.01
PHP Version 5.3.2-1ubuntu4.7
Memory Limit 128 MB
PDO Driver MySQL 5.1.41
No APC or other extra caches

So, what happened?
Without any viewable reason the startpage an other pages returned a 500 status code. I can log into the manager and after deleting the cache, the problem is gone.
I had this problem for the last weeks. Sometimes once a week, sometimes 2-3 times/day. First on another server, where I could’nt inspect the logfiles. So I moved the installation to one of my systems and promised my customer, that everything would be better now :/ First server had a CentOS, PHP 5.2 and so on. So it was different from the new one. I made some experiments with Caching-Duration, disabled APC ... but nothing worked. The URL moved from another (6 years old) CMS and a lot of images and links are gone now. So I have many 404.

But there is only the status 500. No other error logs in php, apache or modx-log.

With the help of this thread, I found the same patterns. Often the 500 appears after a bot visit and a 404. So I changed the following and until now, it seems good:

I placed a robots.txt in the root
I made an custom error-page an disabled the cache for this
Made sure, that only www.domain.de is used

... Damn! While I’m writing this, my error-reporting told me that the site is gone again. I really do not want to disable the cache. First the site gets very slow and second: I want to solve this problem!
My customer send a newsletter yesterday and it seems, that "higher" Traffic (well, not so high: ~100 Users/hour) causes the problems too.

I will take a look at the log immediately and give you some more details :/

Sorry for the poor english. I had not so much sleep this night wink

Greetings from germany,

Sebastian

6 Posts

greex Reply #60, 15 years, 7 months ago

Quote from: greex at Feb 11, 2011, 04:59 AM

I will take a look at the log immediately and give you some more details :/

As I thought before, only the apache access_log tells a little story.
Before I copy & paste only the lines that are relevant in my opinion: Is there anybody who i can send my whole access_log for the past 5 hours? (zipped only 140KB).

I also have no problem to grant some of you developers access to modx and the server. It’s only one page on this server until now and this site really is no rocket-science wink

But I’m wondering: The first 500 was at 11:32 am. I deleted the cache around 11:45 am. In the meantime there were some more 500er - mostly when my "is-alive-script" checked the page, but also some 200 status codes ... I cannot explain this.

But this time there where no Bot-Requests or 404 immediately before the site went down.