DEPLOY FAQ HACKING LICENSE NEWS README SIGNALS Sandbox Static_Files Summary TUNING Test_Suite rainbows_1 vs_Unicorn
Rainbows ActorSpawn AppPool Base Configurator Coolio CoolioThreadPool CoolioThreadSpawn DevFdResponse Epoll EventMachine FiberPool FiberSpawn MaxBody NeverBlock Rev RevFiberSpawn RevThreadPool RevThreadSpawn Revactor Sendfile ServerToken StreamResponseEpoll ThreadPool ThreadSpawn ThreadTimeout WriterThreadPool WriterThreadSpawn XEpoll XEpollThreadPool XEpollThreadSpawn

Signal handling

In general, signals need only be sent to the master process. However, the signals Rainbows! uses internally to communicate with the worker processes are documented here as well. With the exception of TTIN/TTOU, signal handling matches the behavior of and nginx so it should be possible to easily share process management scripts between Rainbows!, unicorn and nginx.

Master Process

Worker Processes

Sending signals directly to the worker processes should not normally be needed. If the master process is running, any exited worker will be automatically respawned.

Procedure to replace a running rainbows executable

You may replace a running instance of rainbows with a new one without losing any incoming connections. Doing so will reload all of your application code, unicorn/Rainbows! config, Ruby executable, and all libraries. The only things that will not change (due to OS limitations) are:

  1. The path to the rainbows 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 rainbows running now, both of which will have workers servicing requests. Your process tree should look something like this:

    rainbows master (old)
    \_ rainbows worker[0]
    \_ rainbows worker[1]
    \_ rainbows worker[2]
    \_ rainbows worker[3]
    \_ rainbows master
       \_ rainbows worker[0]
       \_ rainbows worker[1]
       \_ rainbows worker[2]
       \_ rainbows worker[3]
  3. You can now send WINCH to the old master process so only the new workers serve requests. If your rainbows 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.

  4. You should now ensure that everything is running correctly with the new workers as the old workers die off.

  5. If everything seems ok, then send QUIT to the old master. You're done!

    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.


mail archives: https://yhbt.net/rainbows-public/
	http://ou63pmih66umazou.onion/rainbows-public/ 
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.rainbows 
	nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.rainbows 
	nntp://news.gmane.io/gmane.comp.lang.ruby.rainbows.general 
public: rainbows-public@yhbt.net
source code: git clone https://yhbt.net/rainbows.git
	torsocks git clone http://ou63pmih66umazou.onion/rainbows.git