unicorn doesn't stop running

[eviltrout]

unicorn doesn't stop running

[ddollar]

Make sure you're running the latest foreman, I fixed a bug with the signals sent on termination a few days ago.

Cheers,
David

[eviltrout]

I thought I was using the git version, but I will confirm.

[jeromelefeuvre]

Same problem with passenger on 0.16.0 version

(feature/Internationalization+) =>> foreman start
09:19:07 web.1 | started with pid 84580
09:19:07 worker.1 | started with pid 84581
09:19:07 spork.1 | started with pid 84582
09:19:10 worker.1 | (in /Users/james/MyProjects/LeadFormance/bridge)
09:19:11 spork.1 | /Users/james/.rvm/gems/ree-1.8.7-2011.03@bridge-dev/gems/spork-0.9.0.rc7/bin/../lib/spork/test_framework/cucumber.rb:2: warning: already initialized constant DEFAULT_PORT
09:19:11 spork.1 | /Users/james/.rvm/gems/ree-1.8.7-2011.03@bridge-dev/gems/spork-0.9.0.rc7/bin/../lib/spork/test_framework/cucumber.rb:3: warning: already initialized constant HELPER_FILE
09:19:11 spork.1 | /Users/james/.rvm/gems/ree-1.8.7-2011.03@bridge-dev/gems/spork-0.9.0.rc7/bin/../lib/spork/test_framework/rspec.rb:2: warning: already initialized constant DEFAULT_PORT
09:19:11 spork.1 | /Users/james/.rvm/gems/ree-1.8.7-2011.03@bridge-dev/gems/spork-0.9.0.rc7/bin/../lib/spork/test_framework/rspec.rb:3: warning: already initialized constant HELPER_FILE
09:19:11 spork.1 | Using RSpec
09:19:11 web.1 | ** ERROR ***
09:19:11 web.1 | The address 0.0.0.0:3000 is already in use by another process, perhaps another
09:19:11 web.1 | Phusion Passenger Standalone instance.
09:19:11 web.1 |
09:19:11 web.1 | If you want to run this Phusion Passenger Standalone instance on another port,
09:19:11 web.1 | use the -p option, like this:
09:19:11 web.1 |
09:19:11 web.1 | passenger start -p 3001
09:19:11 spork.1 | process terminated
09:19:11 system | terminating
09:19:11 system | killing worker in pid 84581

09:19:11 system | killing spork in pid 84582

sorry dude,
Jerome

[ddollar]

Jerome, your issue appears to be unrelated to this issue. You already have a web server listening on port 3000 and the new one is failing to start up. You may want to include -p $PORT in your web command.

[jeromelefeuvre]

in fact, no, it's was a previous foreman start where I kill it with ctrl+c. Got no other running

sorry if I was not clear

[ddollar]

Could you paste the contents of your Procfile here?

[jeromelefeuvre]

sure:

web: bundle exec passenger start
worker: bundle exec rake jobs:work
spork: bundle exec spork

[yfeldblum]

Similar problem (ruby-1.9.2-p180, foreman-0.18.0).

$ cat Procfile
web: bundle exec unicorn -c config/unicorn.rb

$ foreman start web -p 3000
<ctrl+c>
# unicorn should be stopped here, but isn't

$ sudo ps -ef | grep -vw grep | grep unicorn
jay       6272     1 99 Jun17 ?        15:48:26 unicorn master -c config/unicorn.rb                                      
jay       6292  6272  0 Jun17 ?        00:00:42 unicorn worker[0] -c config/unicorn.rb                                   
jay       6295  6272  0 Jun17 ?        00:00:43 unicorn worker[1] -c config/unicorn.rb                                   
jay       6298  6272  0 Jun17 ?        00:00:45 unicorn worker[2] -c config/unicorn.rb                                   
jay       6301  6272  0 Jun17 ?        00:00:48 unicorn worker[3] -c config/unicorn.rb                                   

$ kill -TERM 6272
$ sudo ps -ef | grep -vw grep | grep unicorn
# same as above

$ kill -KILL 6272
$ sudo ps -ef | grep -vw grep | grep unicorn
jay       6292     1  0 Jun17 ?        00:00:42 unicorn worker[0] -c config/unicorn.rb                                   
jay       6295     1  0 Jun17 ?        00:00:43 unicorn worker[1] -c config/unicorn.rb                                   
jay       6298     1  0 Jun17 ?        00:00:45 unicorn worker[2] -c config/unicorn.rb                                   
jay       6301     1  0 Jun17 ?        00:00:48 unicorn worker[3] -c config/unicorn.rb                                   

# wait a couple seconds
$ sudo ps -ef | grep -vw grep | grep unicorn
# empty

[ddollar]

Could you paste a gist to your unicorn config?

[blt04]

I am experiencing the same issue.

My Procfile:

web: unicorn_rails -p $PORT

I have no unicorn config file.

I'm not sure if this helps:

Foreman (actually PTY.spawn) runs the unicorn process using sh -c:

sh -c unicorn_rails -p $PORT

On my machine, this causes a process hierarchy like:

USER      PID   COMMAND
bturner   7186  ruby: foreman master
bturner   7188    \_ ruby: foreman web
bturner   7191        \_ sh -c unicorn_rails -p $PORT
bturner   7194            \_ unicorn_rails master -p 5000
bturner   7196                \_ unicorn_rails worker[0] -p 5000

As far as I can tell, when you send sh -c a SIGTERM signal, it causes that process to terminate, but it's forked child processes (in this case unicorn_rails -p $PORT) does not receive a SIGTERM signal.

To debug, I replaced web: unicorn_rails -p $PORT with web: strace -e trace=signal -o tracefile unicorn_rails -p $PORT. Pressing CTRL+C in foreman, which sends a SIGTERM to pid 7191, causes strace to display:

--- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
rt_sigreturn(0x1a)                      = -1 EINTR (Interrupted system call)

Whereas sending a SIGTERM directly to the unicorn_rails process (pid 7194) causes strace to display:

--- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
rt_sigreturn(0x1a)                      = -1 EINTR (Interrupted system call)
kill(7849, SIGTERM)                     = 0

So, as far as I can tell, sh -c does not pass received signals to child processes. Is there anyway to not use sh -c? Any ideas?

BTW... This is on Ubuntu 10.10 which symlinks sh to dash. The problem appears to be related to dash, bash -c works correctly.