unicorn:reload sometimes doesn't kill the old pid

[abraxas]

I'm having a problem where unicorn:reload is giving me two live unicorn instances (sometimes of different versions!)

I'm sure the base cause for this is a bug in unicorn regarding the USR2 signal... however, I'd love if there were a config option to expand unicorn:reload to unicorn:stop+unicorn:start for verbosity's sake.

Unfortunately, either way means I won't be updating my on the fly without downtime.

[cbetta]

I have discovered the same issue. Works fine for 1 app and then for the other app I end up with "old" instances.

[sosedoff]

Are you using master or 0.1.6 gem ?

[cbetta]

I tried both your gem and directly from master. I assume the gem was 0.1.6 (latest, right?)

[cbetta]

I am going to try and debug this today. Will make a Pull Request if I get anywhere

[cbetta]

Ok, I think the current master branch solves most issues. I solved my issues by putting this in my Gemfile:

gem 'capistrano-unicorn', github: "sosedoff/capistrano-unicorn", branch: "master", :require => false

I had tried to do this before but with little success. Turned out it was still pointing at a different gem version in the global gemset. I recommend anyone to run the commands as:

bundle exec cap deploy

You can tell the difference between the current gem and the version in master by looking at the output of cap -T

# output from old gem
cap unicorn:graceful_stop             # Unicorn graceful shutdown
cap unicorn:reload                    # Reload Unicorn
cap unicorn:start                     # Start Unicorn
cap unicorn:stop                      # Stop Unicorn

# output for master version
cap unicorn:add_worker                # Add a new worker
cap unicorn:reload                    # Reload Unicorn
cap unicorn:remove_worker             # Remove amount of workers
cap unicorn:restart                   # Restart Unicorn
cap unicorn:shutdown                  # Immediately shutdown Unicorn
cap unicorn:start                     # Start Unicorn master process
cap unicorn:stop                      # Stop Unicorn

@sosedoff any chance you can roll the current master out as a new gem asap?

[sosedoff]

Yes. Im running some deployment tests right now.

[rajeshkp]

We ran into the same issue related to cap unicorn:reload with the latest gems. On reload, it creates new unicorn master/worker processes. It doesn't kill the old processes before starting the new ones. The pid(s) in the log files still reflect the old unicorn process, so on a successive stop it stop(s) the old process and the new unicorn process is left dangling.

[sfsekaran]

Try using master, @rajeshkp. Let us know if that works.

[sfsekaran]

I'm closing this on account of master seems to be working properly for people. Pushing a new gem version is a separate issue.

[sosedoff]

@sfsekaran let me know when the batch of features is done. also, im not sure if there were any breaking changes.

[sfsekaran]

@sosedoff Ok. I'll try to take a look.

[sfsekaran]

@sosedoff Issue #70 bumps the gem version. We should likely release when that gets merged.

[sosedoff]

@sfsekaran ok