Backend Errors:: Premature end of script headers

Contacted the hoster to see if it is a server load issue to see what is going on and if they can help out?

Hoster blocked loading certain pages partly because the site demanded more than the maximum server load. Will work on trying to optimize. If that does not do the trick I might have to move to a VPS.

Turned on debugging and got:

Notice: Undefined index: aiosp_enabled in domain.com/wp-content/plugins/all-in-one-seo-pack/all_in_one_seo_pack.php on line 766
Notice: Undefined index: aiosp_enabled in domain.com/wp-content/plugins/all-in-one-seo-pack/all_in_one_seo_pack.php on line 766

Is not big deal: https://www.ads-software.com/support/topic/plugin-all-in-one-seo-pack-the-plugin-doesnt-work-for-me-on-wp-30?replies=12

These I am not certain of:

Notice: Use of undefined constant ddsg_language - assumed 'ddsg_language' in domain.com/wp-content/plugins/sitemap-generator/sitemap-generator.php on line 44

Notice: add_option was called with an argument that is deprecated since version 2.3 with no alternative available. in domain.com/wp-includes/functions.php on line 3323

Notice: load_plugin_textdomain was called with an argument that is deprecated since version 2.7 with no alternative available. in domain.com/wp-includes/functions.php on line 3323

Notice: register_sidebar_widget is deprecated since version 2.8! Use wp_register_sidebar_widget() instead. in domain.com/wp-includes/functions.php on line 3237

Notice: register_widget_control is deprecated since version 2.8! Use wp_register_widget_control() instead. in domain.com/wp-includes/functions.php on line 3237

Notice: Undefined index: showcase_middle in domain.com/wp-content/themes/parallelus-unite/theme_admin/includes/sidebars-metaboxes.php on line 102

Notice: Undefined index: showcase_right in domain.com/wp-content/themes/parallelus-unite/theme_admin/includes/sidebars-metaboxes.php on line 112

Not made u my mind on one of these notices being the cause though. Will do some theme/plugin checks..

Error log still shows same errors:

[Wed Mar 16 00:42:02 2011] [error] [client xx.xxx.xx.xxx] Premature end of script headers: index.php
[Wed Mar 16 01:37:05 2011] [error] [client xx.xxx.xx.xxx] Premature end of script headers: index.php, referer: https://domain.com2010/09/page-name/?rcommentid=458&rerror=incorrect-captcha-sol&rchash=00db746f90563a14c8be74d31a7be788#commentform
[Wed Mar 16 01:42:17 2011] [error] [client xxx.xxx.xxx.xxx] Premature end of script headers: wp-cron.php
[Wed Mar 16 02:37:31 2011] [error] [client xx.xxx.xx.xxx] Premature end of script headers: index.php
[Wed Mar 16 03:09:55 2011] [error] [client xxx.xxx.xxx.xxx] Premature end of script headers: wp-cron.php
[Wed Mar 16 03:18:19 2011] [error] [client xx.xxx.xx.xxx] Premature end of script headers: index.php

Checking error log with and without plugins running:

1. Akismet
2. All in One SEO Pack
3. Category Redirect
4. Dagon Design Sitemap Generator
5. Executable PHP widget
6. Formidable
7. Formidable Extension
8. MailChimp Archives
9. Maintenance Mode
10. Mass Custom Fields Manager
11. Morfeo Video Gallery
12. My Page Order
13. NextGEN Gallery
14. Page Links To
15. Quotes Collection
16. RYO Category Visibility
17. Shopp
18. Shortcode Exec PHP
19. The Events Calendar
20. WordPress Importer
21. WP-reCAPTCHA
22. WP Super Cache

Also wonder if any of these plugins are known to eat a lot of memory..

On the sop page I have 55 queries. 0.940 seconds – 71 queries. 1.071 seconds CPU time depending on the page using this code:

<?php echo get_num_queries(); ?> queries. <?php timer_stop(1); ?> seconds

Does not sound like a bad number. And on top of this, this does not help me narrow down the “Premature end of Header Scripts” not the backend 404s.

Reading and following https://openinworld.com/2011/03/wordpress-shared-hosting-performance/ at the moment. Good tips there to lower CPU/Memory

Update: Seems like this site uses a lot (with all 24 plugins running):

Usage Sample: 49MB (19%)
Peak Usage: 75.13MB (29%)
All-Time: 49.19MB on 3/16/11 @ 5:13 am (admin_print_footer_scripts)
Load Averages: 0.47 0.38 0.3
WP Memory Limit: 32M
PHP Memory Limit: 90

But still it did not reach its PHP limit. Just 25% of it.
I guess Dream Host does not appreciate it and that is why the procwatch script keeps on killing the loading of admin pages. Just don’t follow why that is the case as the PHP limit has not been reached according to the TPC! Memory Usage plugin

Update:

Did some more loading of admin pages and had a 404 and update of TPC! data:

Usage Sample: 49MB (19%)
    Peak Usage: 63.4MB (25%)
    All-Time: 53MB on 3/16/11 @ 5:15 am (shutdown)
    Load Averages: 0.36 0.35 0.31
    WP Memory Limit: 32M
    PHP Memory Limit: 90M

Added:

define('WP_MEMORY_LIMIT', '96M');

to wp-config.php

and now have:

Usage Sample: 49MB (19%)
    Peak Usage: 63.4MB (25%)
    All-Time: 53MB on 3/16/11 @ 5:25 am (shutdown)
    Load Averages: 0.43 0.4 0.32
    WP Memory Limit: 96M
    PHP Memory Limit: 90M

Found out the TPC Memory Usage plugin sends loads of update e-mails to the admin. Need to shut that down.

Update:

Cannot shut down notifications, but raised limit to 64 MB and using own email address now. Current stats:

* Usage Sample: 49.46MB (19%)
* Peak Usage: 75.54MB (30%)
* All-Time: 53.39MB on 3/17/11 @ 3:02 am (shutdown)
* Load Averages: 0.13 0.49 0.54
* WP Memory Limit: 96M
* PHP Memory Limit: 90M

I wonder if shutdown means when the server blocked the loading and showed the 404 I got again..

I think it is Shopp that is asking for a lot of memory. Not really using that many queries but using elements in the Shopp backend gets met at 48-50 MB. I think DH cuts the loading around 50 MB if it happens for a while and even perhaps around 45 MB when that amount of memory is used for a while. The posts with extra custom fields demand a lot of queries – 75 to 90 – too though so I am not quite certain yet. Too bad I cannot really leave without the custom fields nor Shopp.

Closing this thread. Apparently the previous developer did not adjust wp-config.php and the database was still being loaded from the old location which caused the server to do more work to connect. So I do believe I will not get any more 404s now.

Well, premature end of script errors still occur, even after I moved the database to the proper location and adjusted wp-config.php. Really lost why the setup is still demanding so much CPU …

I’ve been getting the same problem, and I use Dreamhost as well. I’ll post any significant findings.

@ jrevillini Thanks. Looking forward to your findings!

I’m having similar issues. When this error occurs, I’m thrown out of the admin area, back to the site’s base URL. Is this the common result for anyone else?

In my particular case, I’m using Piwik (installed externally) with WP-Piwik plugin inserting Piwik’s JavaScript tracking code. Even though there is no tracking on the admin pages, this problem only seems to happen when Piwik JS tracking is used on the site.

If this is just a general hosting issue, then maybe Piwik causes excessive memory usage. Any further insight would be greatly appreciated.

PS: I’m on Dreamhost, as well.

UPDATE: I’ve just reproduced this error without the Piwik JS tracking code mentioned above. the WP-Piwik plugin is still active, showing Piwik graphs on the Dashboard. Therefore, this could be a general hosting issue (memory/processes) caused by Piwik. More testing soon…

More testing soon…

Hope you find out more. The site still has the same issue from time to time.

Testing report: I’ve tried two memory monitoring plugins: WordPress System Health and TPC! Memory Usage.

I was able to trigger the bad behavior, resulting in this apache error log entry:

[Thu Aug 11 11:21:46 2011] [error] [client xx.xx.xx.xx] Premature end of script headers: index.php, referer: https://example.com/wp-admin/

(The referer varies depending on what link triggered the failure.)

Unfortunately (well, fortunately, but no cause found):

• No indication of unusual memory spikes (using about 35MB of 90MB max)

The (shared) server is under moderate/heavy load (load averages from 4-9 observed), but I cannot confirm that this triggers the problem.

Piwik Note: I tried all of this with and without WP-Piwik. At this time, I cannot trigger the problem again (it was very reliable this morning). This leads me to believe that this is not based on a particular plugin/script, but more likely a general hosting issue (system utilization).

That’s about all I can do for now. If anyone else can diagnose further, I’m keen to get to the bottom of this bad behavior.

Can anyone else suggest other ways to diagnose this type of failure?