Welcome Guest | Login

killing fastcgi instances to refresh changes is very bad...

Is there another way besides doing "killall -usr1 dispatch.fcgi"? I don't like doing this because at that time some user might be uploading an image. As a result, I get quite a lot of images uploaded without mentioning about their name in the database table. And the users aren't so pleased too :-)

If a graceful restart is not possible, then maybe it is possible to know which fastcgi process runs the app I need to restart?

2007-11-09 12:17 PM

Happycoder - sorry - but when you say "I don't like doing this because at that time some user might be uploading an image"  are you referring to the uses who use your app or the other users on the server ?

2007-11-09 10:30 PM

I am referring to the users who use my app.

2007-11-13 05:43 PM

Hello,

The killall command is usually run to make sure that the changes made to the app is reflected fine asap.

I am not sure about a possible graceful restart other than the same.

2007-11-13 08:24 PM

Regards,
Rahul
This is a big problem. Everyone needs to change their app from time to time, and it's often impractical to schedule late-night downtime just to restart FastCGI. I, for one, have to change my app every day, and I have to do it during normal business hours. Killing the process is just not a sane option if it can destroy your data integrity.

I've heard of a possible solution, but it would require action on HostingRails' part.

Supposedly, the config file for FastCGI (probably just httpd.conf) can include something like this:

FastCgiConfig -autoupdate
...which, I'm told, will cause the following command to restart your FastCGI process and thus activate your changes:

touch -m ~/myappname/public/dispatch.fcgi
We can't view httpd.conf, so I don't know if autoupdate is currently in there or not. But my assumption is that it's not. If it wouldn't cause any problems, would the folks at HostingRails please enable it, so we can change our apps without destroying our data integrity?

2008-05-27 12:23 PM

Hi there, FastCgiConfig -autoupdate is for mod_fastcgi, which is far inferior to mod_fcgid in terms of stability and resource allocation.  I don't believe there is a similar command for the ladder (unless you know of one?)

2008-05-27 07:47 PM

I found a pretty good workaround. It's better than the vanilla killall, anyway. The idea is to give the current requests time to finish, prevent any further requests, and only then kill the fast-cgi processes. Here's the Ruby script:

my_apps = %w(one_app another_app yet_another_app) # You must include ALL your fast-cgi Rails apps, not just the ones you want to restart!
restart_page_path = 'rails_restart.html'
sleep_time = 4 # The number of seconds you want to wait for requests to finish executing. So, if your longest requests take 5 seconds to process, you need at least 5 seconds of sleep to avoid data loss.

username = `whoami`.chomp
home = '/home/'+username
restart_page_str = File.open(restart_page_path, 'r').read

puts 'Checking that Rails apps exist...'
my_apps.each do |app|
	begin
  Dir.chdir "#{home}/#{app}/public"
	rescue SystemCallError
  raise "App #{app} does not exist. Restart aborted. (Looking for: #{home}/#{app})"
	end
end

puts 'Safely turning the apps off...'

my_apps.each do |app|
	Dir.chdir "#{home}/#{app}/public" do
  res_html = File.open('restart.html', 'w') 
  res_html << restart_page_str
  res_html.close
  File.rename '.htaccess', '.htaccess.disabled'
  temp_ht = File.open('.htaccess', 'w')
  temp_ht << "RewriteEngine On\nRewriteRule ^(.*)$ restart.html"
  temp_ht.close
	end
end

puts "Sleeping #{sleep_time.to_s} second(s)..."
sleep sleep_time

puts 'Killing fast cgi processes...'
puts `killall -u #{username} dispatch.fcgi`

puts 'Turning apps back on...'
my_apps.each do |app|
	Dir.chdir "#{home}/#{app}/public" do
  File.delete '.htaccess'
  File.rename '.htaccess.disabled', '.htaccess'
	end
end
Important: Be sure to set the variables at the top. This script assumes that your Rails apps are all stored in subdirectories of your root, e.g. ~/my_rails_app. If that's not the case for you, you'll need to modify the script.

Now, you need a nice HTML file to display to users while your app is restarting. Below is rails_restart.html. It includes some JavaScript to refresh the page automatically after 5 seconds. (That value needs to be at least as long as your sleep time).

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
  <title>The page you were looking for doesn't exist (404)</title>
	<style type="text/css">
  body { background-color: #fff; color: #666; text-align: center; font-family: arial, sans-serif; }
  div.dialog {
  	width: 25em;
  	padding: 0 4em;
  	margin: 4em auto 0 auto;
  	border: 1px solid #ccc;
  	border-right-color: #999;
  	border-bottom-color: #999;
  }
  h1 { font-size: 100%; color: #f00; line-height: 1.5em; }
	</style>
	<script type="text/javascript">
  // The delay needs to be at least as long as the sleep time in the restart script
  setTimeout('window.location = window.location', 5000); // window.location.reload() will resend post data, which we don't want
	</script>
</head>

<body>
  <!-- This file lives in public/404.html -->
  <div class="dialog">
    <h1>We're restarting our systems</h1>
    <p>Don't worry, we'll be offline for less than 10 seconds. If nothing happens after 10 seconds, refresh this page.</p>
  </div>
</body>
</html>
As always, I've tested this code on my webspace, but your mileage may vary. No guarantees of safety.

P.S.: Why does the code indentation get messed up in this forum?

2008-05-28 02:49 PM

Thanks Msjb, 'code looks fine in IE and FF - which browser are you using?

2008-05-29 01:45 AM

I'm using FF 2.0.0.14. The problem seems to be with lines that are indented more than one level. (I use tabs not spaces.)

2008-05-29 02:19 PM


Hello Guest! In order to post you must be an active client with us, please log in or sign up.