Guardfile evaluation stopped by guard-rails until Ctrl+C is pressed

[jbhannah]

After updating guard-rails to 0.3.1 from 0.2.3, when starting Guard, it evaluates the Guardfile until the guard-rails section is reached, starts the server, and then stops evaluating the guardfile. If I press Ctrl+C in the terminal in which Guard is running, it stops the server, continues evaluating the Guardfile, and notifies me that Rails could not be started.

[ranmocy]

@jbhannah Please post up your Guard and Rails version, thanks.

[ranmocy]

@jbhannah BTW, did your Rails server started as expected? It did block the process of evaluation when start the server, but should move on when server start completely. And default timeout is 30secs.

[jbhannah]

I'm using the latest versions of Guard and Rails; here's my Gemfile and my Guardfile. And yes, the Rails server did start as expected, as in the development server was fully functional, but it held up Guard indefinitely—I would never be notified that the server had started completely, and Guard would never move on to evaluating the rest of the Guardfile (Spork and RSpec, in my case) or return to its prompt. The only way to quit it was to Ctrl+C, killing the server, and then it would run everything else, tell me the server couldn't be started, then return to a prompt. This would happen every time it got to evaluating the guard-rails portion of the Guardfile.

[jbhannah]

One more note: I'm currently using Puma and have the debugger enabled, but this behavior occurs with that setup, or when using WEBrick with the debugger disabled. I haven't tested with any other servers or options. It definitely hangs for longer than the default 30-second timeout; I would continute with development as normal for several minutes, even a couple of hours without restarting Guard, and the server behaved as normal—Guard just wasn't doing anything else, be it reevaluating the Gemfile, re-running migrations or RSpec, or reloading Spork.

[maximeg]

I have the same issue.

Having guard-rails and guard-resque, the later runs Resque only after I hit Ctrl+C in guard (that shutdowns webrick).

guard 'rails', :port => 3000 do
  watch('Gemfile.lock')
  #watch(%r{^(config|lib)/.*}) # Not needed because routes & locales already reload well
end

guard 'resque', :environment => 'development', :verbose => true do
  watch(%r{^app/models/(.+)\.rb$})
  watch(%r{^app/jobs/(.+)\.rb$})
  watch(%r{^app/mailers/(.+)\.rb$})
  watch(%r{^lib/(.+)\.rb$})
end

I have the very last stable version for Rails, Guard, and guard-resque & guard-rails.
I'm not using guard-rspec on this nor spork & co.

[jbhannah]

I went back and tested with 0.3.0, and this same issue occurs with that version, so the regression occurred somewhere between versions 0.2.3 and 0.3.0. As noted in the commit where I referenced this post, reverting to 0.2.3 removes the issue.

[maximeg]

Okay, using 0.3.2 it works (it uses spawn)

I looked into it: the error comes in 0.3.1 when you refactored creating the run_rails_command! method : it missed the & at the end of the command run by sh -c.

[ranmocy]

@jbhannah @maximeg
Weird. Since 0.3.1 works for me.
I mean to delete the & because it breaks Guard process in my case.
Any way, I think 0.3.2 should work in any case.

BTW, what kind of OS platform do you guys are using?

[maximeg]

I'm on Ubuntu 12.04

[jbhannah]

OS X. Confirmed that it's fixed with 0.3.3.