Nginx maintenance page

I’m having a little trouble getting the Nginx maintenance pages working
as I’d like them to.

I have the following rewrite rule in my Nginx config file:

if (-f /software/shared/system/maintenance.html) {
rewrite ^(.*)$ /system/maintenance.html last;
break;
}

The problem I’m having is that this maintenance page is only showing up
when the Rails application is still running in the background. If I
kill the Rails app I get a 502 Bad Gateway error and checking the Nginx
error log I see that Nginx is asking the mongrels to server the
maintenance file (but they’re not there as the application isn’t
running!)

I’ve copied in my full config below.

Any help would be greatly appreciated!

Arfon

#user nobody;
worker_processes 5;

pid /software/shared/log/nginx.pid;
error_log /software/shared/log/nginx.error.log;

events {
worker_connections 1024;
}

http {
include /software/shared/config/mime.types;
default_type application/octet-stream;

log_format  main  '$remote_addr - $remote_user [$time_local]

$request ’
'"$status" $body_bytes_sent “$http_referer” ’
‘"$http_user_agent" “$http_x_forwarded_for”’;

access_log  /software/shared/log/nginx.access.log  main;
client_body_temp_path /software/shared/nginx/client_temp 1 2;
proxy_temp_path /software/shared/nginx/proxy_temp 1 2;
fastcgi_temp_path /software/shared/nginx/fastcgi_temp 1 2;

sendfile        on;
tcp_nopush      on;
tcp_nodelay     off;

#keepalive_timeout  0;
keepalive_timeout  65;

gzip              on;
gzip_http_version 1.0;
gzip_comp_level   2;
gzip_proxied      any;
gzip_types        text/plain text/html text/css

application/x-javascript text/xml application/xml application/xml+rss
text/javascript;

  upstream mongrel {
  server myapp.com:6641;
  server myapp.com:6642;
  server myapp.com:6643;
  server myapp.com:6644;
  server myapp.com:6645;
}
server {
    listen       6640;
    client_max_body_size 50M;
    root /software/shared/system;

    #access_log  log/host.access.log  main;
    rewrite_log on;

    if (-f /software/shared/system/maintenance.html) {
      rewrite  ^(.*)$  /system/maintenance.html last;
      break;

    }

   location / {

      # needed to forward user's IP address to rails
      proxy_set_header  X-Real-IP  $remote_addr;

      root   html;
      index  index.html index.htm;

      # needed for HTTPS
      proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $http_host;
      proxy_redirect false;
      proxy_max_temp_file_size 0;

      # If the file exists as a static file serve it directly

without
# running all the other rewite tests on it
if (-f $request_filename) {
break;
}

      # this is the meat of the rails page caching config
      # it adds .html to the end of the url and then checks
      # the filesystem for that file. If it exists, then we
      # rewite the url to have explicit .html on the end
      # and then send it on its way to the next config rule.
      # if there is no file on the fs then it sets all the
      # necessary headers and proxies to our upstream mongrels
      if (-f $request_filename.html) {
        rewrite (.*) $1.html break;
      }

      if (!-f $request_filename) {
        proxy_pass http://mongrel;
        break;
      }
    }

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }
}

}

If I kill the Rails app I get a 502 Bad Gateway error

Short answer: run /etc/init.d/nginx reload after creating
/system/maintenance.html (and do it again after removing the maintenance
file)

It sounds like your Rails processes are serving the maintenance page.
When your
Rails processes are down nginx appears to be still trying to proxy the
request
to Rails - which results in a 502. That implies that nginx is not
attempting to
serve the maintenance.html page at all. This has happened to me in the
past and
I found that I needed to reload nginx.conf for it to pick up a newly
created
maintenance file.

If that doesn’t work, then compile nginx with debugging enabled
(./configure
–with-debug) and add debug_http to the end of your error_log
configuration.
Then you can watch the rewriting rules in action by tailing your
error.log.

On Jul 15, 2008, at 11:54 AM, Arfon S. wrote:

I’m having a little trouble getting the Nginx maintenance pages
working
as I’d like them to.

maintenance pages? is this i feature i missed?

something i could use to replace our own current ones?

can someone point me in the direction of some docs as i cant seem to
find anything on this?

thanks.

-sean-

On Thu, Jul 17, 2008 at 11:34 AM, Thomas [email protected] wrote:

It’s simply a rewrite rule that will deliver the maintenance page (if
it exists) to all incoming request. You still need to design your own
nicely crafted maintenance page though.

My bad, it is not a rewrite rule! It is a rule (no rewrite) for Nginx
to look for a maintenance page, and if it exists, it sends it back no
matter which request is coming in. A rewrite rule is not even needed.

On Jul 17, 2008, at 5:36 AM, Thomas wrote:

On Thu, Jul 17, 2008 at 11:34 AM, Thomas [email protected] wrote:

It’s simply a rewrite rule that will deliver the maintenance page (if
it exists) to all incoming request. You still need to design your own
nicely crafted maintenance page though.

My bad, it is not a rewrite rule! It is a rule (no rewrite) for Nginx
to look for a maintenance page, and if it exists, it sends it back no
matter which request is coming in. A rewrite rule is not even needed.

hmm yes, but would that one prevent any images being on the page?
looks pretty much like ours… in its general idea…

if ( -f $document_root/.maintenance )
{
set $maintenance 1;
}

if ( $uri ~ ^/maintenance/ )
{
set $maintenance 0;
}

if ( $maintenance )
{
rewrite (.*) /maintenance/index.html last;
}

if file exists, serve maintenance. ( with bypass for any other files
in /maintenance ) directory.

It’s simply a rewrite rule that will deliver the maintenance page (if
it exists) to all incoming request. You still need to design your own
nicely crafted maintenance page though.