On Jul 14, 2010, at 12:00 AM, Lawrence Pit wrote:
It appears unicorn rolls back by itself when it can't start the new master.
Nice!
Jamie also mentions to use the shared vendor/bundler_gems path. Though I do
use that in all my projects I'm not so sure it's wise to do when you can't
What about that PATH value? What happens if 10 deployments later the
dir /app/releases/20100714054705 is pruned? I tried. After removing
that dir I could still send a HUP, but when I send a USR2 I get this:
Eric had already pointed me to http://unicorn.bogomips.org/Sandbox.html
before, I
I need to play a bit more with this.. I'll probably have to change my
/etc/init.d/unicorn script so that it starts with the
vendor/bundler_gems version instead of a system-wide version :oI'll
get back to you..
Take a look at http://unicorn.bogomips.org/Sandbox.html According
Changes:
Theses release fix a long-standing bug where the original PID
file is not restored when rolling back from a USR2 upgrade.
Presumably most upgrades aren't rolled back, so it took over a
year to notice this issue. Thanks to Lawrence Pit for
discovering and reporting this issue.
About
Hi Eric,
Thanks mate. Unfortunately this still doesn't seem to work for me.
I went through the process manually, you can see a transcript at
http://pastie.org/1043347.txt
The indented text is what I see appearing in the unicorn stderr.log.
As you can see it reports two errors during the
Lawrence Pit lawrence@gmail.com wrote:
Hi Eric,
Thanks mate. Unfortunately this still doesn't seem to work for me.
I went through the process manually, you can see a transcript at
http://pastie.org/1043347.txt
The indented text is what I see appearing in the unicorn stderr.log.
Hi Eric,
At the top of my pastie http://pastie.org/1043347.txt you can see that
when I request of list of gems it mentions only unicorn v1.1.2
I also added the suggested logging to the before_fork block and I also
logged the unicorn version. Interesting output. First it runs the master
