unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Eric Wong <e@80x24.org>
To: "Jérémy Lecour" <jeremy.lecour@gmail.com>
Cc: unicorn-public@bogomips.org
Subject: Re: Unicorn, environment variables, start and reload
Date: Thu, 23 Apr 2015 09:29:18 +0000	[thread overview]
Message-ID: <20150423092918.GA31792@dcvr.yhbt.net> (raw)
In-Reply-To: <CANrRGgpP3fxo2FPBKCmSz2R34Nv=GeG2i3iXckevx=JQAHC2Xw@mail.gmail.com>

Jérémy Lecour <jeremy.lecour@gmail.com> wrote:
> Hi,
> 
> For some time I've been using Unicorn to serve Rails applications.
> 
> I've been increasingly relying on environment variables to set various
> password and configuration bits outside of the application's code.
> 
> For that I've been using the "dotenv" gem that load a `.env` file into
> the ENV hash. It's great and really useful in development mode, but
> it's not a best practice to use it in production. Here is what Brandon
> Keepers (maintainer of Dotenv) says about this :
> 
> > One of the reasons I don't advocate for using dotenv in production is because it loads the environment variables within the ruby process, which makes it very difficult to track which variables were previously set and which were loaded by dotenv. If you set these variables in the environment of your server (/etc/environment, /etc/profile, etc) then unicorn reloading will just work.

Right, and some of these envs might not work unless they're set before
Ruby VM initialization.  By the time the process can run Ruby code, it's
too late to setup most malloc behavior in any program or GC tuning for
Ruby.

I think most of the MRI-specific RUBY_* vars and most enviroment
variables used for any malloc tuning will fall into this group.

> So I was wondering what would be the correct way to have environment
> variables available in the Ruby process, up-to-date when the Unicorn
> process is started and reloaded too (with USR2).
> 
> And there is also the case of various shell initializations
> (login/non-login, interactive/non-interactive) and supervisors like
> Monit that strip the environment to a minumum before executing the
> start/stop commands.

I set them in an init script (or whatever startup script/system I use).
I might also use "env -i" to clobber any existing environment if
I'm feeling really thorough, but usually I don't.

Most versions of Linux allow checking the environment by inspecting
/proc/$PID/environ  (tr '\0' '\n' </proc/$PID/environ to convert
null-terminated to newlines).  This may not reflect changes done inside
the process, though, so maybe have a private endpoint dump the contents
of ENV.

> I understand that I can do something like this on start :
> 
>     $ source ~/my/app/.env && unicorn [...]
> 
> But what about the reload situation ?

You can change the ENV (or run any other Ruby) in the config file, but
most might not take effect until a new process is spawned (same with
dotenv).  This means you may need USR2 for it to take effect.

I definitely keep ENV changes in the Ruby config file synched with
what's in the init script (and both in version control).

      reply	other threads:[~2015-04-23  9:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-23  9:05 Unicorn, environment variables, start and reload Jérémy Lecour
2015-04-23  9:29 ` Eric Wong [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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=20150423092918.GA31792@dcvr.yhbt.net \
    --to=e@80x24.org \
    --cc=jeremy.lecour@gmail.com \
    --cc=unicorn-public@bogomips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://yhbt.net/unicorn.git/

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).