Workers reaped with SIGABRT - how to debug?

2014-04-15 Thread Henrik Nyh
We get errors like this one a few times a day: Apr 13 12:16:31 app1 unicorn.log: E, [2014-04-13T12:16:31.302011 #17269] ERROR -- : reaped #Process::Status: pid 17300 SIGABRT (signal 6) worker=2 We use Unicorn 4.8.2, Ruby 2.1.1 and a Ruby on Rails app. It doesn't seem to happen at any

Re: Workers reaped with SIGABRT - how to debug?

2014-04-15 Thread Eric Wong
Henrik Nyh hen...@barsoom.se wrote: We get errors like this one a few times a day: Apr 13 12:16:31 app1 unicorn.log: E, [2014-04-13T12:16:31.302011 #17269] ERROR -- : reaped #Process::Status: pid 17300 SIGABRT (signal 6) worker=2 We use Unicorn 4.8.2, Ruby 2.1.1 and a Ruby on Rails

Re: Workers reaped with SIGABRT - how to debug?

2014-04-15 Thread Henrik Nyh
On Tue, Apr 15, 2014 at 10:43 AM, Eric Wong normalper...@yhbt.net wrote: This is may be a bug in a C extension RubyGem or even Ruby itself. Do you get core dumps + backtraces or any other error messages in the logs? You'd expect this to be in the Rails app's production.log, right? We added that

[PATCH] Kill lazy workers with TERM before KILL

2014-04-15 Thread Camilo Lopez
We want to know what was going on with a lazy worker, KILL is un-trappable so we are sending TERM instead, then to make sure the process really dies we are KILLing a second later. --- lib/unicorn/http_server.rb | 31 +++ lib/unicorn/worker.rb | 7 ++- 2 files

[PATCH] Print stack for lazy workers

2014-04-15 Thread Camilo Lopez
This patch attemps at making the debugging of lazy workers easier by making sure unicorn prints a stack trace to STDERR. The patch does 2 things 1. It kills lazy workers with TERM first and then attempts a KILL 2. Prints the stack trace on every kill signal Camilo Lopez (1): Kill lazy