diff options
Diffstat (limited to 'SIGNALS')
| -rw-r--r-- | SIGNALS | 51 |
1 files changed, 51 insertions, 0 deletions
@@ -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. |