From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS14383 205.234.109.0/24 X-Spam-Status: No, score=-0.6 required=5.0 tests=FREEMAIL_FROM, MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,T_DKIM_INVALID shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: Jimmy Soho Newsgroups: gmane.comp.lang.ruby.unicorn.general Subject: Re: javascript disappears Date: Wed, 18 Aug 2010 23:20:49 +1000 Message-ID: References: <20100818011444.GA14052@dcvr.yhbt.net> <20100818024540.GA29950@dcvr.yhbt.net> <20100818071410.GB29950@dcvr.yhbt.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1282139003 4535 80.91.229.12 (18 Aug 2010 13:43:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 18 Aug 2010 13:43:23 +0000 (UTC) To: unicorn list Original-X-From: mongrel-unicorn-bounces@rubyforge.org Wed Aug 18 15:43:21 2010 Return-path: Envelope-to: gclrug-mongrel-unicorn@m.gmane.org X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=EXSMHuAo7FwS4z51xFXWHCxwMMk9OO8SPyLo71sxTlM=; b=B8+qXdAyk2TIE01rT+Uzhwf2oz21uNnRCCGhYXZZOad4dC8gcqxfUBw0TOtOVB+dLF 49vzpdNNzei0JGNjFxE8hexlS2jttrjKgrQXpWJIf2kxIWFAlOMErahMuthkDZ2PtFB5 hKg2idBmR5RyMeVsrMLjUqYaOc9WkPEQ/ceY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=YXsaL24wUtcYY5Z95Om3Lj4sDioCeqaD8tGRxPqWT0BSLmBsHgvAx4afNdsWKfd/qn Q68tf4KZ7loRg00XutIkKlz+L+XPO0Zw6X9Jb/dUThFUmmBkkgjD6KiJTqyS+HenUzd/ NwEvmfjGmcJvkxOZeVTUzOXvuLYeUKyq+LYCI= In-Reply-To: <20100818071410.GB29950@dcvr.yhbt.net> X-BeenThere: mongrel-unicorn@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: mongrel-unicorn-bounces@rubyforge.org Errors-To: mongrel-unicorn-bounces@rubyforge.org Xref: news.gmane.org gmane.comp.lang.ruby.unicorn.general:682 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OlivI-0001pH-Ny for gclrug-mongrel-unicorn@m.gmane.org; Wed, 18 Aug 2010 15:43:21 +0200 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 21844185836B; Wed, 18 Aug 2010 09:43:20 -0400 (EDT) Received: from mail-pv0-f178.google.com (mail-pv0-f178.google.com [74.125.83.178]) by rubyforge.org (Postfix) with ESMTP id 732A61858374 for ; Wed, 18 Aug 2010 09:20:50 -0400 (EDT) Received: by pvh1 with SMTP id 1so231942pvh.23 for ; Wed, 18 Aug 2010 06:20:49 -0700 (PDT) Received: by 10.142.192.1 with SMTP id p1mr6997848wff.223.1282137649771; Wed, 18 Aug 2010 06:20:49 -0700 (PDT) Received: by 10.143.132.8 with HTTP; Wed, 18 Aug 2010 06:20:49 -0700 (PDT) > Aha! I believe there's an option for Bundler to use the /srv/app/shared > directory with Capistrano. That's probably your best option. I am using the shared bundler gems option, I use the example floating around the internets: run("cd #{release_path} && bundle install vendor/bundler_gems --without development test --disable-shared-gems") > You can also try force the environment variables with the > before_exec hook in your config file: > > before_exec do |server| > ENV['GEM_HOME'] = '/srv/app/current/vendor/bundler_gems' > end After a few hours hacking I've come to the conclusion that's the only way it can work, for now. Having delved into bundler I think Bundler.setup needs to change. I'll file an issue for that with them. PS. I: for those interested, this is now the unicorn-conf.rb file I'm using, so I can now happily prune all old releases: http://gist.github.com/534668 PS. II: While I trying out various things I found that if I modified the before_exec hook, then deployed that code, send USR2, then it executes the before_exec hook of the old master, not the new master. So I then had to send a USR2 a second time to see the new code in before_exec taking effect. Is that intentional behaviour? PS. III: Haven't tested it yet, but in case a USR2 fails, and unicorn reverts back to the old master, does the old master then have the new environment variable values? Or does it run the before_exec hook again for the old master? Jimmy _______________________________________________ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying