[pmwiki-devel] Internal server error message

[Randy Brown]

Thanks for all the avenues to investigate.

The problem happens whether I'm editing or just reading pages, and on any page that invokes php. (Direct html works fine.) I'll keep a closer eye on my error log next time the issue arises.

This may also have something to do with my host: I see from Top that on my shared server at the moment virtual memory is 12300528k total, 12000484k used, yet my own processes in the list show zero CPU or memory. 

Regardless of my woes, I didn't know about some of the limitations you mentioned. That's important information. Perhaps those limitations are all documented, but of the list you mentioned, I only recall seeing the one about avoiding PTVs that are based on other PTVs. I didn't know there were issues with PTVs using markup expressions and conditionals. Is there a good page to document such limitations?

I do find that a pagelist template that invokes another pagelist can be a very useful technique. Would it be hard to make that work in some future version of PmWiki?

Randy


On Oct 8, 2014, at 2:22 PM, Petko Yotov <5ko at 5ko.fr> wrote:

> Is there anything in the Apache error_log?
> 
> Does it happen when you edit pages, or when you only read pages of your wiki? Does it happen to specific pages, or not? Does it always happen to the specific pages, or sometimes it happens, sometimes it doesn't for the same page?
> 
> Have you enabled some recipes? Does the problem still appear when the recipes are disabled?
> 
> Do you have some complex wiki markups like embedded pagelists? Pagelists are not really designed to be embedded in other pagelists (there is a global $Cursor variable which may get overwritten and lead to infinite loops and crashes). If that's the case, there is no easy solution.
> 
> Do you have complex page text variables (PTVs) containing other page text variables, or containing markup expressions, or conditionals? It is possible that at some point there is an infinite loop which consumes all the CPU/RAM resources of the server. Recent PmWiki versions try to detect the embedded PTVs and exit the infinite loops, but there might be something it fails to detect.
> 
> The automatic tasks that PmWiki does from time to time are:
> - updating the wiki.d/.pageindex file for faster searches, this might rarely cause high CPU/RAM usage, if your files reside on a network hard drive attached to the server;
> - retrieving the blocklists from the internet, this might rarely cause high CPU/RAM usage if your server doesn't have a stable/fast incoming internet connection
> - processing the blocklists: look at the downloaded blocklist pages (in SiteAdmin/): if they look like HTML, try disabling those blocklists. In the past blocklist providers have dropped their websites so wikis were getting content from some cybersquatters which was not adapted for the blocklist engine.
> 
> There may be more cases, but as you can imagine, intermittent errors are hard to debug.
> 
> Petko
> 
> On 08.10.2014 19:26, Randy Brown wrote:
>> For the past few weeks, all the wikis I've tested have developed an
>> occasional problem: when pmwiki.php is running, the server runs out of
>> virtual memory and is unable to create a child process. I get an
>> "Internal Server Error" message. It seems to occur for anywhere from a
>> few minutes at a time to a few hours, and during that time if I keep
>> trying I'll get a certain percentage of successful response - it can
>> range mostly successful to rarely successful.
>> My web host says that when they accessed one site my account suddenly
>> went from 0 to 100% virtual memory usage.
>> The problem occurs even on websites that I haven't changed for months.
>> When it's happening to one site, it's happening to the others too.
>> I've tried adjusting in php.ini the max_memory allowed, both up and
>> down, with no effect.
>> I get the problem even when I block all IP addresses except for my
>> own.
>> The only theory I can think of is that some cron job that PmWiki runs
>> in background, such as blocklist, is starting to consume tons of
>> memory for reasons unknown. But I would think that such an issue would
>> affect lots of websites, not just mine, and I haven't seen this
>> problem reported before, so it seems unlikely.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-devel/attachments/20141008/e2cb7169/attachment.html>