Using Unicorn web server

Unicorn is a web server that uses forked processes to handle multiple incoming requests concurrently.

Deploy with Unicorn

To run a Unicorn web server, add a line to your Procfile labeled as custom_web. Here is an example:

custom_web: bundle exec unicorn_rails -c config/unicorn.rb -E $RAILS_ENV

You can change freely between other supported servers by simply updating your Gems and Procfile.

Don't daemonize custom_web

You should not daemonize the custom_web process. In other words, please do not use the -D or -daemonize flags in your initialization string. Please also make sure your config file does not enable daemonization.

We do not support old-style daemonization because it is more reliable to allow the system's process manager (systemd) to handle persistent processes.

Sample config file for Unicorn

This unicorn.rb configuration file is compatible with Cloud 66 requirements (following the Procfile initialization string above, this should be located under the config folder of your Rails app):

worker_processes 2

working_directory "#{ENV['STACK_PATH']}"

listen "#{ENV['CUSTOM_WEB_SOCKET_FILE']}", :backlog => 64

timeout 30

pid "#{ENV['CUSTOM_WEB_PID_FILE']}"

stderr_path "#{ENV['STACK_PATH']}/log/unicorn.stderr.log"
stdout_path "#{ENV['STACK_PATH']}/log/unicorn.stdout.log"

preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
	GC.copy_on_write_friendly = true

check_client_connection false

before_fork do |server, worker|
	old_pid = "#{ENV['CUSTOM_WEB_PID_FILE']}.oldbin"
	if File.exists?(old_pid) && server.pid != old_pid
		begin
			Process.kill("QUIT", File.read(old_pid).to_i)
		rescue Errno::ENOENT, Errno::ESRCH
			# someone else did our job for us
		end
	end

	defined?(ActiveRecord::Base) and
		ActiveRecord::Base.connection.disconnect!
end

after_fork do |server, worker|
	defined?(ActiveRecord::Base) and
		ActiveRecord::Base.establish_connection
end

Customizing shutdown and reload signals

The default shutdown command for Unicorn servers on Cloud 66 is USR2 and the default shutdown sequence for applications using systemd (our default process manager) is:

quit, 75, term, 15, kill

If you need your web server to shut down using a different command, or in a particular sequence, or with longer or shorter delays, you can define a custom restart sequence in the procfile_metadata section of your Manifest file.

For non-web process signals, please consult our systemd guide.

Controlling Unicorn via your terminal

You can manage your web server directly from your terminal. Cloud 66 uses the following signals to control Puma via systemd:

Stop the web server

sudo systemctl stop cloud66_web_server.service

Start the web server

sudo systemctl start cloud66_web_server.service

Restart the web server

sudo systemctl restart cloud66_web_server.service