From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 7FFEE201B0; Tue, 21 Feb 2017 19:43:20 +0000 (UTC) Date: Tue, 21 Feb 2017 19:43:20 +0000 From: Eric Wong To: Jeremy Evans Cc: unicorn-public@bogomips.org Subject: Re: Patch: Add after_worker_exit configuration option Message-ID: <20170221194320.GA26617@whir> References: <20170221191923.GH93742@jeremyevans.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170221191923.GH93742@jeremyevans.local> List-Id: Jeremy Evans wrote: > This option can be used to implement custom behavior for handling > worker exits. For example, let's say you have a specific request > that crashes a worker process, which you expect to be due to a > improperly programmed C extension. By modifying your worker to > save request related data in a temporary file and using this option, > you can get a record of what request is crashing the application, > which will make debugging easier. > > This is not a complete patch as it doesn't include tests, but > before writing tests I wanted to see if this is something you'd > consider including in unicorn. What advantage does this have over Ruby's builtin at_exit? AFAIK, at_exit may be registered inside after_fork hooks to the same effect. Thanks.