adagiomarine

I got hosting service to increase timeout to 5 minutes. That solved the problem. The export was about 5,600 posts.

MichaelH — thanks heaps for the quick reply. On the K2 support forum Michael Heilemann suggested much the same, pointing me to the K2 Child Theme docs. I’ve not been keeping up with development and did not know about the inheritance implementation of the child-theme. That should make the maintenance of WP and K2 updates much easier.

I’m having what seems to be the same problem on WP 2.3.2. Any suggestions would be much appreciated!

Disabling all plugins did not fix the problem.

I’ve checked mail server logs – no related errors. I’ve tested with different unfiltered email addresses on two different blogs [same host]. Nothing comes through.

Any tips on troubleshooting much appreciated.

A followup to make this thread complete for future reference. Further testing indicates that the source of these problems is the combination of PHP 4.4.4 and the Google Sitemap plugin.

Our web host luxsci.com updated to PHP 4.4.4 late evening on Sept 9. Not long after our site error log shows the first instance of this error:

[Sat Sep 9 22:18:59 2006] [error] ALERT – script tried to increase memory_limit above allowed value (attacker ‘142.179.100.111’, file ‘/xd1/homes/hash/41/a2141/90/05/u20590/seekerblog.com/www/wp-content/plugins/sitemap.wp2/sitemap.php’, line 1516)

Where line 1516 is:
ini_set(“memory_limit”,”128M”);

Our web host confirms that their administrative memory limit [8MB] overrides the ini_set() call. I speculate that v4.4.4 changed the way ini_set() operates – perhaps the prior versions didn’t generate an error when the requested limit could not be established?

I have also installed the WordPress 2.0.4 update and retested – the error persists.

I just added the sitemap tag to this post. And I’ve emailed the plugin author Arne Brachhold.

My workaround is to disable the plugin until this is resolved.

Any other suggestions welcomed.

HandySolo,

> you got the default 8MB?

That is a very good point – thanks heaps for that insight. In fact the test I just completed may confirm your thesis. I had the “test” mySQL instance restored to Sept 1 – before the mystery errors. And of course a somewhat smaller database. If my thesis was correct it should have worked.

But it didn’t – same errors – until I deactivated the Google Sitemap plugin. I think this points to the PHP update in some way – your thesis being a leading candidate. It could also be a 4.4.4 issue in the Google Sitemap plugin.

I’ve found the problem I think, by snapshoting the error log before/after attempting a new post [via xmlrpc]. This generated 2 log entries [see below]. I disabled the Google Sitemap plugin –>> all works OK now.

I think what happened is the size of mySQL database reached a point two weeks ago which caused the Sitemap plugin to need more memory. I’ll report this to Arne Brachhold.

[Tue Sep 19 08:39:46 2006] [error] ALERT – script tried to increase memory_limit above allowed value (attacker ‘142.179.103.65’, file ‘/xd1/homes/hash/41/a2141/90/05/u20590/seekerblog.com/www/wp-content/plugins/sitemap.wp2/sitemap.php’, line 1516)
[Tue Sep 19 08:39:53 2006] [error] ALERT – configured GET variable value length limit exceeded – dropped comment (attacker ‘212.248.241.2’, file ‘/xd1/homes/hash/41/a2141/90/05/u20590/seekerblog.com/www/index.php’)
[Tue Sep 19 08:40:41 2006] [info] [client 202.108.1.5] (104)Connection reset by peer: client stopped connection before rwrite completed

vkaryl,

>I’ve had wp working normally for the last couple of months on the backend versions

Thanks, that’s helpful to know. Are you running 2.0.2 or …?

I’m considering asking web host to restore Sept 1 backup to my test blog – i.e., content prior to the mystery. If that works, do I have a “corrupt dbms”? Then what?

Updated problem isolation tests:

To isolate between SQL dbms problems and WP install directory problems, I have had web host restore the production mySQL rows into the test instance. Now both WP install directories and mySQL dbms are identical between test and production blogs.

And now the seekerblog.com/test instance fails identically to the production case.

That implies to me that the problem is associated with the SQL dbms rows.

Thanks in advance for suggestions on what to do next. E.g., is there any way the PHP v4.4. or Apache 1.3.37 updates could cause this problem?

> don’t triple post

Sorry moshu – and thanks for the followup.

I thought the original had been deleted, so I rewrote the original post, adding my latest test results which seem to confirm that the problem goes with the mySQL dbms rows. I’ll add those details to the original now.

Forgot to note blog URL where I am testing…

https://www.seekerblog.com/

From adagiomarine: case closed!

Three days since my query, suddenly all of the above reported faults have gone walkabout. Good thing too, as this was a real puzzler.

I can only infer that hosting svc LuxSCI.com has changed something that fixed the problem. I shall inquire…

Yes – which built the sitemap, and I presume create the new page “Sitemap”. I can’t find anything in the docs about the plugin and what is supposed to be the Page content.

I found a fix: increasing the PHP memory [did this test on Beta 3.0b1]. To the function BuildSitemap() I added the following:

//Increase memory
ini_set(“memory_limit”,”128M”);

I did not test to determine smallest memory allocation that would work.

Update: I just tried the latest beta v3.0b1. Same result.