I'm using Rails 3.0.5 version and Ruby 1.9.2 in my application.
Its working fine in development mode but in production mode server goes down after every 3-4 days.
It gives below error in /var/log/https/error.log file.
[Sun Oct 21 09:39:03 2012] [error] [IP_ADDRESS] **Premature end of script headers:**
[ pid=24971 thr=1 file=ext/apache2/Hooks.cpp:817 time=2012-10-21 09:39:03.371 ]:
The backed application (process 29805) did not send a valid HTTP response; instead, it sent nothing at all. It is possible that it has crashed; please check whether there are crashing bugs in this application.
I am not getting what's the reason for server down.
which server your using? webrick or else? i got some problem like this in past that server goes down. i changed server from webrick to Mongrel its faster then webrick
Sorry i can't comment so answering, personally haven't come across this problem but there seems to be quite some talk about it. Here are a few resources that i came across:
Dalibor Nasevic's explanation as to why this is happening
Premature end of script headers — Rails
Intermittent “premature end of script headers” with Rails 3.1
Hope it helps.
Related
My centos server is running web applications in LAMP stack. A couple of days back, the server was not responding for about 10 mins and I got http response failure alert from my monitoring tool. When I checked the httpd error log I found a huge log entry (~12000 lines) related to sendmail.
14585 sendmail: fatal: open /etc/postfix/main.cf: Permission denied
The server ran out of memory and not responding.
14534 [Fri Aug 19 22:14:52.597047 2016] [mpm_prefork:error] [pid 26641] (12)Cannot allocate memory: AH00159: fork: Unable to fork new process
14586 /usr/sbin/sendmail: error while loading shared libraries: /lib64/librt.so.1: cannot allocate version reference table: Cannot allocate memory
We are not using sendmail in any of our application. How can I stop this attack in future?
Thank you in advance!
Sorry I have no comment facilities; it looks like one of your website pages is vulnarable for code injection, finding out where and what page may be a huge job. Focus on input (forms) variables. Always sanitize input variables before using them! P.s. php uses "sendmail", even if you use Postfix, it will use a sendmail binary to send mail and the sendmail binary will redirect it to Postfix. If your forms work well and the 12k error log lines come out of the blue, then I would think someone is trying to inject code through your website (happens all the time by the way).
In the configuration file example for Puma, it says the following for the on_restart function:
Code to run before doing a restart. This code should close log files,
database connections, etc.
Do I need to implement this for a Rails app, to close connections to the db and the logfile, or is that taken care of automatically? If not, how do I actually do all that?
No you don't, Rails takes care of reloading your code automatically. But this code reloading support is limited. For example changes to application.rb are not applied until you restart the app server.
But I would recommend Phusion Passenger over Puma. Phusion Passenger is a lot easier to setup, especially when you hit production. Phusion Passenger integrates into Apache and Nginx directly and provides advanced features like dynamic worker management. Phusion Passenger is very mature, stable and performant and used by the likes of New York Times, Symantec, AirBnB, etc.
I've found that using Redis as my Rails.cache provider causes an error page upon the first request every time my Rails/Puma server is restarted. The error I got was:
Redis::InheritedError (Tried to use a connection from a child process
without reconnecting. You need to reconnect to Redis after forking.)
To get around this error, I didn't add anything to on_restart, but did have to add code to on_worker_boot ( I am running Puma with workers=4 ):
puma-config.rb
on_worker_boot do
puts "Reconnecting Rails.cache"
Rails.cache.reconnect
end
Im building my first Rails app server on a Ubuntu server machine. I came to the point where i am testing a simple add located on the server. When I hit the root page, default rails message
"Welcome on board, You’re riding Ruby on Rails!"
Thats good i suspect. But when I hit server/todos i just get this error message
"We're sorry, but something went wrong."
How can I see full error message? I am completely new to Apache and Passenger. I suspect I could get full messages if i run from the server but there is no GUI or browser installed.
Ok found out this was all connected to the Rails app and not a Apache or Passenger setting.
# environments/production.rb
config.consider_all_requests_local = true
I've been having problems getting Passenger up and running on my Ubuntu 10.04 box (see https://stackoverflow.com/questions/9243272/passenger-ruby-on-rails-issues).
I've finally got it working, but now logging doesn't work. logs/production.log only sporadically gets notifications (and they come in chunks), and /var/log/apache2/error.log only logs cache misses.
I've set PassengerLogLevel to 2, but still am not getting much information in the Apache error log.
What did I do wrong?
Thanks!
Turns out it's a reported issue in Rails 3.2.x
https://github.com/rails/rails/issues/4277
Another possible solution is that the Passenger-process has no writing rights to your log-directory. If it cannot open these files for writing, you will start seeing log-messages in /var/log/apache2/error.log
At least it was like this in our case.
Anyone using repcached?
Basically, I am experimenting with it in order to use it for storing sessions there, while providing failover with its buildin replication
Basically, I have 2 nodes running centos 5.4. The replication works fine wi\hen testing it and running some benchmarks with ab.
However, I am doing the below test.
I am having the 2 nodes started and replicating and start an ab test. While the benchmark is running, I take down one of the node, just to check the fail over.
At that point apache's error log starts printing
[Fri Oct 15 21:39:02 2010] [notice] child pid 2941 exit signal Segmentation fault (11)
It seems that some requests fail during the fail over
Anyone encountered such behavior?
Thanks
It turns out that this is caused by php's client memcache client.
Installing version 3.0.3 from pecl did the trick
The error appears with versions 3.0.4 and 3.0.5
I hope it will save people time