maemo.org Bugzilla – Bug 3280
Wiki pages sometimes fail to load with "lost network connection"
Last modified: 2008-11-24 16:36:47 UTC
You need to
before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM:
1. Browse the wiki
Wiki pages load consistently
Page fails to load with a "lost network connection"
Sometimes. Seems to happen more often over https than http (error message is
slightly different over http, too).
X-Fade said he was looking into this last week. Something about the Apache
thread segfaulting. It's rather severely impacting the usability of the wiki,
though, so the priority may need to go up a bit.
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US)
AppleWebKit/525.18 (KHTML, like Gecko, Safari/525.20) OmniWeb/v618.104.22.168362
The problem here appears to be at least partly that mediawiki is installed on
the same server as Midgard, which is also slowed down to the point of giving
errors through time-outs. The server they're on is due an upgrade, but right
now, I don't know what, if anything, is being done to address the problem.
Could you please post the exact error message once you see this again? You
could see such 'lost connection' type of message when I restarted memcache,
after reconfiguration. It always takes a few seconds and a few requests until
memcache 'wakes up'. Such reconfiguration did not happen in the last two days,
or so. If you see the error again, please take a screenshot, or just copy-paste
the text you see in your browser (unless it is an HTTP 5xx error and your
browser gives a special page for you).
I leave the bug as is now, and if there is no update let's say in a week that
we can mark it as 'WORKSFORME' for example. Thanks.
(In reply to comment #2)
> Could you please post the exact error message once you see this again? You
> could see such "lost connection" type of message when I restarted memcache,
> after reconfiguration. It always takes a few seconds and a few requests until
> memcache "wakes up". Such reconfiguration did not happen in the last two days,
> or so. If you see the error again, please take a screenshot, or just copy-paste
> the text you see in your browser (unless it is an HTTP 5xx error and your
> browser gives a special page for you).
It's happened to me 7 or 8 times today already, and I know Jaffa ran into it at
least once today. The exact error message is in the initial report and the
summary, I'll grab a screenshot next time I see it, though. ;) Over http the
error message is actually from the server (rather than the browser), and is
something along the lines of "lost connection to 127.0.0.1". I don't browse the
wiki over http, though, so haven't seen it in a while.
Created an attachment (id=805) [details]
Screenshot showing the browser error while browsing the wiki
This error occurred at 2017 UTC.
Thanks. I am able to reproduce the problem, which is an apache segfault. Just
keep hitting ctrl-r for a while and soon there is the log message about apache
crashing. I am not an apache expert in this sense, so i wish someone could give
me a hand here, or some tips (enabling debug log did not give me more clues).
It is obvious that the box is overloaded by serving the wiki, the application
catalog and the rest of maemo.org pages, but that will be the last to say we
need new hardware (which we do btw ;)
Any good URLs for apache debugging?
It is very easy to get a full blank page when going to http://wiki.maemo.org
(no https). I have experienced this myself. See also the comments at
Proposing to put this bug as dependent of the resolution of
http://wiki.maemo.org/Task:Fast_Server - MEDIUM
This seems to be fixed now that the wiki is running on a more powerful
infrastructure. Resolving as FIXED, please reopen if you think otherwise.
(In reply to comment #8)
> This seems to be fixed now that the wiki is running on a more powerful
> infrastructure. Resolving as FIXED, please reopen if you think otherwise.
Sorry, no, got a couple more browsing the wiki this evening.
Should be fixed since Squid is gone, haven't noticed any blank pages so far.