about summary refs log tree commit homepage
path: root/SIGNALS
diff options
context:
space:
mode:
authorEric Wong <normalperson@yhbt.net>2009-03-19 18:50:39 -0700
committerEric Wong <normalperson@yhbt.net>2009-03-19 20:19:05 -0700
commite9be891dc851015eaf592d3c64caff77398f1246 (patch)
treeb62f7b58f99258c1423b1caea9a553579c5a5bf2 /SIGNALS
parentc01c8ccae6a4b500d0aebd385c10f4567d9b0fd3 (diff)
downloadunicorn-e9be891dc851015eaf592d3c64caff77398f1246.tar.gz
This will only be enabled if we're daemonized and "real" WINCH
signals cannot be generated by resizing the terminal.  This is
to avoid confusing developers who run in the foreground of a
terminal.

Additionally document procedures for reexecuting a running
binary.
Diffstat (limited to 'SIGNALS')
-rw-r--r--SIGNALS51
1 files changed, 51 insertions, 0 deletions
diff --git a/SIGNALS b/SIGNALS
index c7c3833..b1a3141 100644
--- a/SIGNALS
+++ b/SIGNALS
@@ -22,6 +22,9 @@ processes are documented here as well.
    should be sent to the original process once the child is verified to
    be up and running.
 
+ * WINCH - gracefully stops workers but keep the master running.
+   This will only work for daemonized processes.
+
 === Worker Processes
 
 Sending signals directly to the worker processes should not normally be
@@ -34,3 +37,51 @@ automatically respawned.
 
  * USR1 - reopen all logs owned by the worker process
    See Unicorn::Util.reopen_logs for what is considered a log.
+
+=== Procedure to replace a running unicorn executable
+
+You may replace a running instance of unicorn with a new one without
+losing any incoming connections.  Doing so will reload all of your
+application code, Unicorn config, Ruby executable, and all libraries.
+The only things that will not change (due to OS limitations) are:
+
+1. The listener backlog size of already-bound sockets
+
+2. The path to the unicorn executable script.  If you want to change to
+   a different installation of Ruby, you can modify the shebang
+   line to point to your alternative interpreter.
+
+The procedure is exactly like that of nginx:
+
+1. Send USR2 to the master process
+
+2. Check your process manager or pid files to see if a new master spawned
+   successfully.  If you're using a pid file, the old process will have
+   ".oldbin" appended to its path.  You should have two master instances
+   of unicorn running now, both of which will have workers servicing
+   requests.  Your process tree should look something like this:
+
+   unicorn master (old)
+   \_ unicorn worker[0]
+   \_ unicorn worker[1]
+   \_ unicorn worker[2]
+   \_ unicorn worker[3]
+   \_ unicorn master
+      \_ unicorn worker[0]
+      \_ unicorn worker[1]
+      \_ unicorn worker[2]
+      \_ unicorn worker[3]
+
+4. You can now send WINCH to the old master process so only the new workers
+   serve requests.  If your unicorn process is bound to an interactive
+   terminal, you can skip this step.  Step 5 will be more difficult but
+   you can also skip it if your process is not daemonized.
+
+5. You should now ensure that everything is running correctly with the
+   new workers as the old workers die off.
+
+6a. If everything seems ok, then send QUIT to the old master.  You're done!
+
+6b. If something is broken, then send HUP to the old master to reload
+    the config and restart its workers.  Then send QUIT to the new master
+    process.