It happened nohup wasn't the problem (but the solution!). The issue was that the environment uses by cap was very different, and the workers were failing silently with exceptions.
Marcelo. On Fri, Oct 8, 2010 at 3:55 PM, Marcelo de Moraes Serpa <[email protected]> wrote: > Thanks a lot for the comprehensive answer, Lee. > >>Since this won't create a pty/login shell, there are a chance your scripts >>are struggling to write debugging info since typically there is no >stdin, to >>prompt a user if there's a problem, and the environment in which it runs is >>completely different from if you were to SSH-in >manually and explore the >>state of the machine. > > I see. Adding RAILS_ENV=production before each system call seems to > fix the problem. I do have to use nohup though, or none of the workers > are started. > > Interestingly enough, although the workers are started, they don't > seem to be working / catching the messages. Any ideas? > > Marcelo. > > > On Fri, Oct 8, 2010 at 2:50 AM, Lee Hambley <[email protected]> wrote: >> Hi Marcello, >> >> There's a debugging point I need to improve in the documentation, it goes >> something like this… if your ssh_options[:pty] [1] is set true, then your >> cap commands emulate a login shell [2], otherwise you are running a >> non-login shell (recommended). >> >> To emulate and test the behaviour of your wrapper scripts under a non-login >> shell, you should do something like this to emulate them: >> >> $ ssh 111.222.333.44 'my command here' >> >> Since this won't create a pty/login shell, there are a chance your scripts >> are struggling to write debugging info since typically there is no stdin, to >> prompt a user if there's a problem, and the environment in which it runs is >> completely different from if you were to SSH-in manually and explore the >> state of the machine. >> >> Note this could be any number of things, but it's always prudent to do >> something like: >> >> set :ruby, '/usr/bin/ruby' >> set :rake, '/usr/bin/rake' >> >> And use those in your commands: >> >> system("#{ruby} #{worker_script} 1 &") >> >> (of course, you're using a wrapper script, but what I'm trying to say is >> that you can't rely on the ENV being the same when you use Capistrano as it >> is when you log in, because it will almost never be.) >> >> Hope some of this helps. >> >> - Lee >> >> [1] http://help.github.com/capistrano/ >> [2] http://en.wikipedia.org/wiki/Unix_shell >> >> -- >> * You received this message because you are subscribed to the Google Groups >> "Capistrano" group. >> * To post to this group, send email to [email protected] >> * To unsubscribe from this group, send email to >> [email protected] For more options, visit this group >> at http://groups.google.com/group/capistrano?hl=en > -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
