unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Eric Wong <e@80x24.org>
To: Simon Eskildsen <simon.eskildsen@shopify.com>
Cc: unicorn-public@bogomips.org, Jeremy Evans <code@jeremyevans.net>
Subject: Re: after_worker_exit on murder
Date: Wed, 5 Apr 2017 01:19:32 +0000	[thread overview]
Message-ID: <20170405011932.GA24739@starla> (raw)
In-Reply-To: <CAO3HKM6SuoR8oFDQ=rafegWVXWj+84_ekQCSm9-6NOoD9OcwiQ@mail.gmail.com>

Simon Eskildsen <simon.eskildsen@shopify.com> wrote:
> With Jeremy Evans' work on `after_worker_exit`, I was hoping I could
> replace our internal fork which has a `before_murder` hook to report
> to monitoring systems when workers are forcibly killed. However, the
> `after_worker_exit` is only called on reaping—not when murdering.

Hi Simon, it looks like Jeremy clarified after_worker_exit for you.

Anyways...  I remember rejecting patches to add more to timeout
support in unicorn over the years since I did not want it to be
a crutch for application developers, or worse; a reason for
people to feel locked into unicorn.  Instead I wrote things like
https://bogomips.org/unicorn/Application_Timeouts.html to
discourage relying on unicorn's built-in `timeout' feature.

But, it seems like there's still a reliance on the built-in

Why is that?  (If you're allowed to disclose)

I don't mean to put you guys (Shopify) on the spot,
as I'm sure other folks do it, too; but you're here :)

Anyways, is this something that could or should be improved
in Rack or ruby itself?  Or are there buggy external libraries
or even external dependencies like NFS to blame?

(Or, perhaps "I don't know" is fine :)

The Ruby timeout handling in stdlib could be way better if
done natively, I think.  Perhaps `ensure` could be better
declared, too; but there's still the problem of getting
external code to work well with it...

Anyways I am of two minds; on one hand, buggy code is fine!
unicorn handles it by nuking a process.  But on the other
hand... it's irritatingly inefficient and shoving things under
the rug still rots and stinks eventually.

  parent reply	other threads:[~2017-04-05  1:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-04 14:08 after_worker_exit on murder Simon Eskildsen
2017-04-04 14:32 ` Jeremy Evans
2017-04-04 14:36   ` Simon Eskildsen
2017-04-05  1:19 ` Eric Wong [this message]
2017-04-05 10:55   ` Simon Eskildsen
2017-04-05 18:33     ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170405011932.GA24739@starla \
    --to=e@80x24.org \
    --cc=code@jeremyevans.net \
    --cc=simon.eskildsen@shopify.com \
    --cc=unicorn-public@bogomips.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).