My GoDaddy Rails site has been plugging away for a couple of weeks. Its just a proof of concept with very little use. I haven''t updated it or restarted FCGI at all. But today, it just quit working altogether. In the error log, I''m getting: (104)Connection reset by peer: FastCGI: comm with server "dispatch.fcgi" aborted: read failed FastCGI: incomplete headers (0 bytes) received from server "dispatch.fcgi" I did some searching on these, and most of the suggested cures were to reinstall FCGI. I deleted the session files, restarted the FCGI processes, but nothing changed the behavior. At this point, I''m wondering if maybe its just my particular server that''s hosed, or if GoDaddy has upgraded something in the environment that might be affecting Rails and FCGI in general - anyone else using GoDaddy seeing a sudden onslaught of weird behavior around Wed afternoon? It''s starting to look like this is a cheap and easy solution, but not necessarily workable even for an app that you just want to demo now and then . . . SR
Steven, I completely feel your pain. Over the past month I''ve struggled with GoDaddy time and time again. I was helping a friend with an app that we got running two weeks ago and last week it stopped working out of nowhere. There haven''t been any code changes and I started seeing this message in the production log: product.rb:2: parse error, unexpected tCONSTANT, expecting $ vti_timelastmodified:TR01 Aug 2006 17:07:07 -0000 So I opened up a ticket and got the following response from GoDaddy support: "Thank you for contacting customer support. Unfortunately we are unable to provide third party scripting assistance via this forum. We apologize for any inconvenience this may cause." No insight to what was causing the problem, just a friendly "it''s your problem not ours" answer. Like I said this came out of nowhere and I''m now investigating other Rails hosting services. I too think something has changed with GoDaddy''s hosting environment, but am to the point where I''m ready to switch. They''ve caused me too much time and frustration and my app performance is horrible! Even running FastCGI I''ve run into 10-15 second response times for basic requests. At any rate, I just wanted to let you know that you''re not alone and needed to vent a little :) Good luck, Dennis -----Original Message----- From: rails-bounces@lists.rubyonrails.org [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Steven Rogers Sent: Thursday, August 10, 2006 1:54 AM To: rails@lists.rubyonrails.org Subject: [Rails] More GoDaddy Woes My GoDaddy Rails site has been plugging away for a couple of weeks. Its just a proof of concept with very little use. I haven''t updated it or restarted FCGI at all. But today, it just quit working altogether. In the error log, I''m getting: (104)Connection reset by peer: FastCGI: comm with server "dispatch.fcgi" aborted: read failed FastCGI: incomplete headers (0 bytes) received from server "dispatch.fcgi" I did some searching on these, and most of the suggested cures were to reinstall FCGI. I deleted the session files, restarted the FCGI processes, but nothing changed the behavior. At this point, I''m wondering if maybe its just my particular server that''s hosed, or if GoDaddy has upgraded something in the environment that might be affecting Rails and FCGI in general - anyone else using GoDaddy seeing a sudden onslaught of weird behavior around Wed afternoon? It''s starting to look like this is a cheap and easy solution, but not necessarily workable even for an app that you just want to demo now and then . . . SR _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails
Just to add to the go-daddy bashing, although this isn''t rails related... I had a dedicated server, in production, with GoDaddy. One day, the server started going down for no apparent reason. Keep in mind, this was in production with a few sites that have reasonable traffic. Several calls to support and the same response "please put in a reboot request". The request can only be scheduled in 15 minute intervals. As soon as it would come back, it would go down within 2-3 minutes. Then I had to wait another 10 minutes for a reboot request. We kept calling were eventually told we were overloading our server (we had 3 web sites and about 100 email boxes) and basically it wasn''t their problem because they can''t support anything that we are running that is causing it to go down. After some deep investigating throughout the evening (during the brief periods between reboot requests), I found the core-temp had been getting pretty high generally right before the server would lock up. After telling go-daddy this, they finally decided to investigate. They found there was a bad fan on our server and it was causing the system to overheat and shutdown. Needless to say, we were really pi$$ed about this. For the first few hours of the issue, GoDaddy wouldn''t even acknowledge the problem could be on their end, and wouldn''t even investigate. They had kept telling us they were looking into it. We were watching "who" on the server, and nobody had ever logged in. Now, of course, hardware fails all the time, I can''t be angry about that--- but the level of service and responsiveness by GoDaddy was horrible... as if it really didn''t even matter to them (not that I suppose it does). The best is that while we were waiting for a response from level1-tech who was waiting on a response from level2-tech, he said "You know, I see here your account has a few domains up for renewal, would you like to consider renewing for 5-10 years?". He then asked if we would like to switch our server plan from month-to-month to a yearly contract. I just laughed. When the fan finally got switched, we got a new server with rackspace and cancelled the godaddy one a couple days later. I even transferred my domains off their registrar (paying transfer fees to the new registrar) just out of spite. -----Original Message----- From: rails-bounces@lists.rubyonrails.org [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Dennis Baldwin Sent: Thursday, August 10, 2006 10:35 AM To: rails@lists.rubyonrails.org Subject: RE: [Rails] More GoDaddy Woes Steven, I completely feel your pain. Over the past month I''ve struggled with GoDaddy time and time again. I was helping a friend with an app that we got running two weeks ago and last week it stopped working out of nowhere. There haven''t been any code changes and I started seeing this message in the production log: product.rb:2: parse error, unexpected tCONSTANT, expecting $ vti_timelastmodified:TR01 Aug 2006 17:07:07 -0000 So I opened up a ticket and got the following response from GoDaddy support: "Thank you for contacting customer support. Unfortunately we are unable to provide third party scripting assistance via this forum. We apologize for any inconvenience this may cause." No insight to what was causing the problem, just a friendly "it''s your problem not ours" answer. Like I said this came out of nowhere and I''m now investigating other Rails hosting services. I too think something has changed with GoDaddy''s hosting environment, but am to the point where I''m ready to switch. They''ve caused me too much time and frustration and my app performance is horrible! Even running FastCGI I''ve run into 10-15 second response times for basic requests. At any rate, I just wanted to let you know that you''re not alone and needed to vent a little :) Good luck, Dennis -----Original Message----- From: rails-bounces@lists.rubyonrails.org [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Steven Rogers Sent: Thursday, August 10, 2006 1:54 AM To: rails@lists.rubyonrails.org Subject: [Rails] More GoDaddy Woes My GoDaddy Rails site has been plugging away for a couple of weeks. Its just a proof of concept with very little use. I haven''t updated it or restarted FCGI at all. But today, it just quit working altogether. In the error log, I''m getting: (104)Connection reset by peer: FastCGI: comm with server "dispatch.fcgi" aborted: read failed FastCGI: incomplete headers (0 bytes) received from server "dispatch.fcgi" I did some searching on these, and most of the suggested cures were to reinstall FCGI. I deleted the session files, restarted the FCGI processes, but nothing changed the behavior. At this point, I''m wondering if maybe its just my particular server that''s hosed, or if GoDaddy has upgraded something in the environment that might be affecting Rails and FCGI in general - anyone else using GoDaddy seeing a sudden onslaught of weird behavior around Wed afternoon? It''s starting to look like this is a cheap and easy solution, but not necessarily workable even for an app that you just want to demo now and then . . . SR _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails
Dennis Baldwin wrote:> I completely feel your pain. Over the past > month I''ve struggled with GoDaddy time and > time again. > > I''m now investigating other Rails hosting services.I''ve been using a2hosting for the past month or so with very good results. I recommend you check them out. Best regards, Bill
Bill,
Thanks much, I will check them out. As a follow-up to my previous email
I was able to finally get the app working after hacking a bit and
finding this in the error log:
"Cannot find gem for Rails =1.1.3:
Install the missing gem with ''gem install -v=1.1.3 rails'',
or
change environment.rb to define RAILS_GEM_VERSION with your desired
version."
Supposedly GoDaddy only supports 1.0.0. Yet changing RAILS_GEM_VERSION
in environment.rb to 1.0.0 still caused problems:
"Cannot find gem for Rails =1.0.0:
Install the missing gem with ''gem install -v=1.0.0 rails'',
or
change environment.rb to define RAILS_GEM_VERSION with your desired
version."
I decided to comment out that line completely as a last resort and the
app started working. Who knows, it will probably break next week, but
at least it will buy me some time until I make the switch.
Thanks again,
Dennis
-----Original Message-----
From: rails-bounces@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Bill Walton
Sent: Friday, August 11, 2006 7:55 AM
To: rails@lists.rubyonrails.org
Subject: Re: [Rails] More GoDaddy Woes
Dennis Baldwin wrote:
> I completely feel your pain. Over the past
> month I''ve struggled with GoDaddy time and
> time again.
>
> I''m now investigating other Rails hosting services.
I''ve been using a2hosting for the past month or so with very good
results.
I recommend you check them out.
Best regards,
Bill
_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails
On Aug 11, 2006, at 3:14 PM, "Dennis Baldwin" <dbaldwin@sensorlogic.com> wrote:> I decided to comment out that line completely as a last resort and the > app started working. Who knows, it will probably break next week, but > at least it will buy me some time until I make the switch.That worked for me too. Using the RAILS_GEM_VERSION at 1.0.0 worked for a couple of weeks, but died on Wednesday. Commenting that out completely works today. Thanks for the heads-up. Like you said, it buys some more time before cutting over to something else. SR
Glad to hear it. I''ve seriously tried everything to get my apps running on GoDaddy and thought I was losing it when I rolled this hack. Please post your findings re hosting and I''ll do the same. Thanks! -----Original Message----- From: rails-bounces@lists.rubyonrails.org on behalf of Steven Rogers Sent: Fri 8/11/2006 6:00 PM To: rails@lists.rubyonrails.org Subject: RE: [Rails] More GoDaddy Woes On Aug 11, 2006, at 3:14 PM, "Dennis Baldwin" <dbaldwin@sensorlogic.com> wrote:> I decided to comment out that line completely as a last resort and the > app started working. Who knows, it will probably break next week, but > at least it will buy me some time until I make the switch.That worked for me too. Using the RAILS_GEM_VERSION at 1.0.0 worked for a couple of weeks, but died on Wednesday. Commenting that out completely works today. Thanks for the heads-up. Like you said, it buys some more time before cutting over to something else. SR _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 3174 bytes Desc: not available Url : http://wrath.rubyonrails.org/pipermail/rails/attachments/20060813/2fc512e2/attachment.bin