If the parent unicorn died, bash and sh would exit and upstart would respawn the whole thing.
Am I missing something? On Tue, May 7, 2013 at 3:53 PM, Ben Hoskings <b...@hoskings.net> wrote: > In that case, how does it spawn a new version of itself? > > > On 7 May 2013 15:00, Chris Berkhout <chrisberkh...@gmail.com> wrote: > >> I don't have unicorn daemonize, so upstart keeps the pid of the bourne >> shell it started (which runs bash, which runs unicorn). >> >> # service restful_geof status >> restful_geof start/running, process 2777 >> # ps -F -p 2777 >> UID PID PPID C SZ RSS PSR STIME TTY TIME CMD >> root 2777 1 0 1099 612 0 May06 ? 00:00:00 /bin/sh >> -e /proc/self/fd/9 >> >> upstart doesn't know anything about the child unicorns. I'm not sure >> whether that could lead to zombies. I think it won't necessarily if unicorn >> manages the child processes properly. >> >> >> >> On Tue, May 7, 2013 at 2:27 PM, Paul Annesley <p...@annesley.cc> wrote: >> >>> >>> On 07/05/2013, at 2:15 PM, Samuel Richardson <s...@richardson.co.nz> >>> wrote: >>> >>> > Interesting. I've tried switching over to Upstart a couple of times >>> but ran into trouble with it monitoring Sidekiq (I think, I can't remember >>> exactly what process it was but it had forking behaviour). >>> >>> Probably not Sidekiq, I don't believe it forks. >>> It's threaded and uses https://github.com/celluloid/celluloid >>> >>> ~/github/sidekiq ⸩ ack --ruby '^[^#]*fork' >>> # $? == 1 >>> >>> Unicorn certain forks, though. Also, Resque I believe. >>> >>> — Paul >>> >>> >>> > >>> > Because of that, I'd stuck with monit as I could just point it at a >>> PID file and be done with it. >>> > >>> > Runit with the REST interface looks very nice though. >>> > >>> > Samuel Richardson >>> > www.richardson.co.nz | 0405 472 748 >>> > >>> > >>> > On Tue, May 7, 2013 at 2:12 PM, Michael Pearson <mipear...@gmail.com> >>> wrote: >>> > This was a long time ago, so it's fuzzy, but: its configuration >>> language was confusing, it had confusing semantics for stopping/starting >>> jobs, and it didn't log output at all, so you had no idea _why_ a >>> particular process wasn't starting or stopping properly. >>> > >>> > I then switched to runit, which was pretty simple (and good). >>> > >>> > When I upgraded our systems to Ubuntu 12.04 I checked out upstart, and >>> they'd made many improvements since what shipped with 10.04 (including >>> output logs), and I haven't looked back. >>> > >>> > >>> > On Tue, May 7, 2013 at 2:09 PM, Samuel Richardson < >>> s...@richardson.co.nz> wrote: >>> > While I'm enjoying this tangent on unicorn behaviour, I'm also an avid >>> Monit user. What were your problems with it? >>> > >>> > Samuel Richardson >>> > www.richardson.co.nz | 0405 472 748 >>> > >>> > >>> > On Tue, May 7, 2013 at 2:08 PM, Michael Pearson <mipear...@gmail.com> >>> wrote: >>> > Oh, one time? >>> > >>> > My start/stop script got out of whack (protip: monit is terrible, use >>> runit or upstart instead) and so I had to say "that's not working because >>> the system is overrun with rogue unicorns" >>> > >>> > Okay I'm done. >>> > >>> > >>> > On Tue, May 7, 2013 at 12:35 PM, Michael Pearson <mipear...@gmail.com> >>> wrote: >>> > Unicorn is excellent because you can say things like: >>> > >>> > "are there any unicorns still alive?" >>> > "Oh, crap, we have zombie unicorns" >>> > >>> > and >>> > >>> > "The master unicorn has spawned a new child. Once the new child has >>> spawned all of its new unicorns, and they have grown up, it will kill the >>> older master unicorn, and all of its children will die" >>> > >>> > This is otherwise known as sending it the USR2 signal. >>> > >>> > On Wed, May 1, 2013 at 10:20 AM, Ben Hoskings <b...@hoskings.net> >>> wrote: >>> > We run two production rack/sinatra apps at TC. I recommend nginx + >>> unicorn. >>> > >>> > This is how I do it (it's badly named; it's not rails-specific): >>> https://github.com/conversation/babushka-deps/blob/master/rails.rb#L1-L4 >>> > >>> > - Ben >>> > >>> > >>> > >>> > On 1 May 2013 10:00, Steve H <st...@kotiri.com> wrote: >>> > I've had good luck with Unicorn. I use it with nginx but Apache will >>> work equally well, as you just reverse proxy a port or unix socket. >>> > >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ruby or Rails Oceania" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to rails-oceania+unsubscr...@googlegroups.com. >>> To post to this group, send email to rails-oceania@googlegroups.com. >>> Visit this group at http://groups.google.com/group/rails-oceania?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rails-oceania+unsubscr...@googlegroups.com. >> To post to this group, send email to rails-oceania@googlegroups.com. >> Visit this group at http://groups.google.com/group/rails-oceania?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Cheers > Ben > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rails-oceania+unsubscr...@googlegroups.com. > To post to this group, send email to rails-oceania@googlegroups.com. > Visit this group at http://groups.google.com/group/rails-oceania?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceania+unsubscr...@googlegroups.com. To post to this group, send email to rails-oceania@googlegroups.com. Visit this group at http://groups.google.com/group/rails-oceania?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
