Errors using Drupal on a Dreamhost account

Same problem here. The errors seemed to have died down for a while, but they're back in the last few weeks.

I have been fighting the EXACT same problems with a GoDaddy shared hosting account.
Drupal 6.17

It's driving me insane. Been trying to figure this out for a week. Sometimes site will be zippy, and admin pages load fast with no errors. Other times (like 5 or 10 minutes later), 500 errors galore - and if the admin pages do load, they take a really long time. Of course GoDaddy says there is nothing wrong on their end, and it must be some "buggy code".

Pulling my hair out.

Are the problems your are have with the Dreamhost memory limits on their shared severs, vps, or dedicated servers, or all three? And are the problems limited to the admin pages?

Same problem here.
I even try to move to a vps server to see if the issue's gone.

The speed is fast. Server load is low. No persistent script.
But still get several 500 error from the anonymous user everyday.

Similar problem with some Wordpress accounts on Dreamhost

http://wordpress.org/support/topic/500-internal-server-errors-with-dream...

But regardless, the problem is that you are using too much memory, and that your PHP processes are hitting our process watcher which is why it's showing the 500 error.

http://wordpress.org/support/topic/admin-sometimes-404-links-mainly-404-...

In my log files I'm seeing "Premature end of script headers", and Dreamhost has responded that their process watch is killing these for exceeding my allowed RAM usage.

http://wordpress.org/support/topic/dreamhost-issues-with-wp-using-too-ma...

my sites give me 503 and 500 server errors, and I mailed them about it. They responded by saying their prochost script said my user (which all the blogs ran under) was using too many resources

Here is a response I received:

"I know you dont want to hear it, but it is indeed still your memory
usage:

2010-08-01 11:41:51 procwatch2 INFO: Process(pid=xxxxx, name='php5.cgi',
uid=xxxxxxxx(1234567), tty=None, cpu=0.0, rss=43888.0, vsize=155908.0):
kill for total RAM

You should try to focus on the following sites:"

I have removed my account details for privacy reasons but here is what this suggests to me... every site is combined underneath a single uid. RAM is calculated for each user, not each website. If this is the case, having a few websites hosted will pretty much render them useless.

I don't think there is a solution to this from Drupal's end. Even if the admin memory usage was reduced, you would still reach their memory limits after a few sites because it is RAM calculated per user. I personally am at breaking point and seriously considering alternate hosts.

Some months ago the "php_value memory_limit" directive worked well in .htaccess file, but now it seems not to be counted.

My .htaccess:

php_value memory_limit 128M
php_value max_execution_time 180
php_value max_input_time 180
php_value post_max_size 80M

But in phpinfo() in same directory, these settings are still in default & unchanged:

memory_limit 90M
max_input_time 60

Config: CGI / FastCGI.

Does anyone? (I have not tried to contact DH support yet).

Edit: Since known issue is php_value does not affect in CGI mode, adding ini_set() directly in PHP file works.

@jerdiggity Thanks for suggesting to create multiple users. I have created a user for every site run on the Dreamhost account and it has solved the problem. As mentioned, it creates a different problem where upgrading modules and the core is laborious. For now it works. In the future I think Dreamhost will figure out what people are doing to bypass their painful restrictions which will be the point at which I choose a different host. Restricting multiple Drupal sites to the same 150mb(estimate of limit) of memory is very irritating.

Hope this helps people with the same issue at the moment.

Can't wait to try it, I've been lurking in the forums daily, for months, trying to find a solution to this problem!

I found this thread trying to figure out why I am getting premature end of headers... with a PHP application. (This app is not actually using drupal.)
however, this thread was infomrative and helped me examine some different possibilities, especially this fcgi / execCGI stuff.

Im on a Dreamhost VPS. Everything was running fine until I switched from the standard DH php.ini to my own custom PHP ini. I used the instructions below to create my fgc-wrapper et al. : http://wiki.dreamhost.com/PHP.ini

once I created the wrapper and my own customized php.ini, things *seemed* to work except for one particular PHP file. That file was getting this error. This file was unique because it was calling into image functions like imagecopy(). The others were not.
After pulling my hair out, I found that removing this statement from one of my own include files stopped the premature.. errors:
error_reporting (E_ALL | E_NOTICE | E_STRICT );
Once this was removed (actually it was removing E_STRICT that made the difference) I stopped getting this error. My application was working again. However, my logs started showing:
23:29:56] PHP Warning: imagecopy(): supplied argument is not a valid Image resource in /home/..../image.php

Interestingly, this E_STRICT was not a problem until I started using the fcgi-wrapper and my own php.ini.

The problem for me seems to have been the combination error level (strict) combined with calling a function in a module which resulted in a warning message. The function, warning aside, worked fine until I started using the fcgi/execCGI wrapper.

It might be worth looking into whether Drupal ends up in similar combination cases. Does it call into functions which in some pages/cases return warnings? Where such a case would fail with the premature end of headers error on DH, does it succeed but with warnings somewhere else? Does drupal use E_STRICT?

This is a shot in the dark, but thought it was worth passing along.

The symbolic link method listed above worked like a charm. I was able to keep my multisite install and manage memory without getting any "process killed" warnings, or 500/404 errors.

Perfect!

I was having these same issues. I have a Dreamhost VPS (Dreamhost PS) and also dedicated MySQL memory resources. In Windows on Chrome I was getting this: Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error.

On Safari I was getting a 500 error.

I ended up going into the php.ini and changing PHP script and memory usage limits. That ended up not fixing it but I'll leave the changes anyway. What stopped all these erorrs for me was just increasing the guaranteed memory on the PS. I had 300MB and doubled it to 600MB, and so far everything is pretty fast.

Important update: In the last few weeks, Dreamhost changed how security works, so it is no longer possible to have separate accounts that point to the same Drupal install as I mentioned above. The support tech's response to my inquiry:

Our security team had to make some changes recently which affected using
multiple users. The "Enhanced Security" feature is now enabled for all
users on shared hosting. More information about this feature is available
on our wiki at .

This is just a further enforcement of our One User Per Domain policy,
.

Unfortunately, functions like custom Unix user groups and remapped
subdirectories across users no longer function. You can temporarily
disable this from the panel's Manage Users page, but the system will
re-enable it without warning, and eventually that ability to disable it
even temporarily will be gone.

This policy change for our shared hosting servers only. The ability to
turn off Enhanced Security is still available for on a VPS or dedicated
server. I'm not trying to tell you to give us more money, but just to lay
out the available options for you. The simple fact is that VPS and
dedicated servers have many magnitudes less users per server, and the
account security of the thousands of users on each shared hosting server
took precedence.

I contacted support because I noticed that the group that used to contain all of my accounts no longer contains any accounts. So a separate account could no longer access my central Drupal install unless I added undesirable world permissions to the site.