# Live restarts of a supervised unicorn process

DevFeed: [Live restarts of a supervised unicorn process](<https://devfeed.tech/articles/live-restarts-of-a-supervised-unicorn-process-41330.md>)

Original publisher: [Read original article](<https://samsaffron.com/archive/2013/11/13/live-restarts-of-a-supervised-unicorn-process>)

Author: Sam Saffron

Published: 2013-11-13T04:59:56Z

Content type: tutorial

Language: en

Sources: [Sam Saffron](<https://devfeed.tech/sources/sam-saffron.md>)

Topics: [Scripting, bash](<https://devfeed.tech/topics/scripting-bash.md>), [Script](<https://devfeed.tech/topics/script.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [Processes](<https://devfeed.tech/topics/processes.md>), [HTTP](<https://devfeed.tech/topics/http.md>)

Tags: [bash](<https://devfeed.tech/tags/bash.md>), [docker](<https://devfeed.tech/tags/docker.md>), [downtime](<https://devfeed.tech/tags/downtime.md>), [rails](<https://devfeed.tech/tags/rails.md>), [script](<https://devfeed.tech/tags/script.md>), [uptime](<https://devfeed.tech/tags/uptime.md>), [zero](<https://devfeed.tech/tags/zero.md>)

## AI overview

The article describes using a Bash script as a stable-pid proxy and mini-supervisor for Unicorn to coordinate live restarts under supervisors such as runit. It also presents a throttled HTTP request script for measuring downtime during restarts and reports zero downtime with the proposed method.

## Source excerpt

We have all seen this dreaded screen before. In the Rails case this usually happens during application restarts. While Discourse is rapidly evolving we are heavily encouraging users to upgrade frequently, even weekly. If your site is regularly erroring out, users very quickly lose confidence. In the ideal case you want zero downtime deploys. This feature heavily encourages users to deploy more rapidly. Unicorn has built-in support for live restarts, however getting this to play well with a supervisor like say runit is not easy. Underlying pids are changing and stuff gets complicated fast. To tackle this I decided to create a simple bash script that acts as a mini-supervisor for unicorn. However, before any of this I needed some sane way of measuring how well I did. ###Measuring uptime during a live restart Traditionally you would use apache bench for quick and dirty testing, however it did not fare well for me. Unfortunately ab has no way of "throttling" the amount of requests it sends out. To measure uptime we need to perform a request to the site every N milliseconds. I ended up knocking up a quick and dirty apache bench clone that allows me to trickle through requests: require "optparse" require "uri" require "net/http" duration = 10 per_second = 10 opts = OptionParser.new do |opts| opts.banner = "Usage: bench_web [options] url" opts.on("-t", "--time TIME", OptionParser::DecimalInteger, "Duration to run the test in seconds (default 10)") do |t| duration = t end opts.on("-p", "--per-second REQUESTS", OptionParser::DecimalInteger, "Max number of requests per second (default 10)") do |t| per_second = t.to_f end end opts.parse! if ARGV.length != 1 puts opts.banner puts exit(1) end uri = begin URI(ARGV[0]) rescue puts opt.banner puts puts "Invalid URL" puts exit(1) end GC.disable finish_time = Time.now + duration results = [] while (start=Time.now) < finish_time res = Net::HTTP.get_response(uri) req_duration = Time.now - start results << {duration: req_duration, code: