Guard: Ctrl-C crashes guard

I am also experiencing this on 2.2.5.

I am also experiencing this (effectively same stack trace), but using Ruby v2.3.0, Guard v2.13.0.

If I run Guard via bundle exec guard and then press Ctrl-C at the prompt, I see the issue. However, if I run guard not through bundle, Pressing Ctrl-C does not cause the issue.

Full Ruby and Readline versions:

$ ruby -v
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15.5.0]

$ ruby -rreadline -e 'puts Readline::VERSION'
6.3

After the Pry prompt errors out, I get terminal corruption similar to what is described here:
https://github.com/pry/pry/issues/1275
https://github.com/pry/pry/issues/1183
https://github.com/guard/guard/issues/719

If I manually install the rb-readline gem, this fixes the corruption issue that occurs afterwards, but Ctrl-C yields the same stacktrace. With this gem installed, guard reports my Readline version as follows:

[1] guard(main)> Readline::VERSION
=> "5.2"

Getting exactly the same issue here... as @WilHall suggests, outside bundler is fine.

$ ruby -v
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin14]
$ guard -v
Guard version 2.14.0

My Readline version is 6.3 both inside guard and outside.

It looks like a combination of a few things.

I'll likely create a "quickfix" branch and later work out how to integrate it.

Ok, I creates a branch with some hacks: https://github.com/guard/guard/tree/experimental_fixes

Here's how to use in in a Gemfile:

gem 'guard', github: 'guard/guard', branch: 'experimental_fixes'

Then bundle update and bundle exec guard as usual.

Also, you may want to try disabling notifications to see if that helps also:

bundle exec guard -n f

Please report problems as well as fixes.

Some issues this should fix:

1. Pry should stop crashing when exiting guard with ctrl-C
2. Output after last lines shouldn't hide the shell prompt underneath
3. Both TMux and TerminalTitle notifiers seem to cause problems with output
4. I haven't checked but it's possible that LumberJack logging is using time flushing when it shouldn't.
5. STDERR stream is no longer closed
6. Pry is no longer killed and joined - it's waken up instead (so it shouldn't "hang" given the other tweaks)

Some regressions/issues:

1. If a guard/task screws up the colored output, it won't be fixed (resetting the console has been disabled).
2. No tests for this (I'm trying to see if I can fix issues first)
3. Not tested on other Rubies than MRI 2.3.1

Other workarounds:

If you're desperate, you can try using Guard without Pry and without notifications:

bundle exec guard -n f -i

Let me know if this helps or has other issues, so I can work towards officially fixing and releasing.

Feel free to submit PRs that selectively use any of these fixes (though tests would be good).

I've pushed some tweaks.

You can pull those changes (or bundle update if you use the above Gemfile line) add then this to your Guardfile to see if it helps:

UI.options.merge!(flush_seconds: 0, level: :debug, device: 'guard.log')
notification :off

It will also log the errors into guard.log. (Though that may trigger scanning the whole directory on OSX).

Thanks @e2, unfortunately I haven't had much luck:

• Crashing behaviour on Ctrl-C remains the same with the "experimental_features" branch when run without additional flags.
• Supplying -n f makes no difference.
• Using the -i parameter prevents crashing when Ctrl-C'ing in tests (though is hard to quit!).

I often get one of the following exceptions now when quitting with Ctrl-D, perhaps a race condition:

19:56:17 - INFO - Bundle already up-to-date
19:56:17 - INFO - Guard is now watching at '/mnt/data1/home/andrew/projects/042-joinly/joinly-app'
^Clog writing failed. can't modify frozen IOError
➜  joinly-app git:(master) ✗
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/commander.rb:69:in `stop': undefined method `destroy' for #<Guard::Jobs::Sleep:0x0056104497dd80> (NoMethodError)
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/commander.rb:53:in `start'
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/cli/environments/valid.rb:16:in `start_guard'
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/cli.rb:122:in `start'
[...]

And

19:56:29 - INFO - Bundle already up-to-date
19:56:30 - INFO - Guard is now watching at '/mnt/data1/home/andrew/projects/042-joinly/joinly-app'
^CE, [2016-08-01T19:56:38.584021 #10597] ERROR -- : run() in thread failed: stream closed:\n /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:300:in `readpartial'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:300:in `readpartial'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:271:in `read_events'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:238:in `process'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:221:in `run'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/listen-3.1.5/lib/listen/adapter/linux.rb:39:in `_run'
[...]

The Guardfile lines with bundle exec guard -n f seems to introduce a delay to the error. Pressing Ctrl-C during a test run still causes Pry to detach with the test continuing to write to STDOUT mixed with an active prompt. But it ends the same way:

[1] guard(main)> Error: Input/output error - read
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/repl.rb:198:in `readline'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/repl.rb:198:in `block in input_readline'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/input_lock.rb:115:in `interruptible_region'

Thanks @Odaeus for checking this out.

First, I screwed up the non-pry interactor. (I just pushed a commit, to fix this).

Second, you ran into this rb-inotify bug: https://github.com/nex3/rb-inotify/pull/59

For which I created a fix (not merged or released yet).

Until then, you use this in your Gemfile:

gem 'rb-inotify', github: 'e2/rb-inotify', branch: 'e2-fix_ioerror_when_closed'

That will solve problem 2.

For problem 3 - that's probably a work in progress, but make sure you have in your Guardfile:

UI.options.merge!(flush_seconds: 0, level: :debug, device: 'guard.log')
notification :off

And you can use tail -f guard.log on the output in another window.

I'm worried the whole Pry session handling would have to be redesigned to fix this properly. That'll probably take a whole Saturday to work out :(

If I have anymore patches I'll let everyone here know ASAP.

Ok, this should work (as far as I can tell):

In your Gemfile:

 gem "guard", github: "guard/guard",
                branch: "experimental_fixes", ref: "c6ab8a0"

 gem "listen", require: false, github: "guard/listen",
                branch: "advanced_thread_debugging", ref: "31053de"

  gem "guard-rspec", require: false, github: "guard/guard-rspec",
                     branch: "ctrl_c_workaround", ref: "ee0b21d"

  gem "rb-inotify", require: false, github: "e2/rb-inotify",
                    branch: "e2-fix_ioerror_when_closed", ref: "99d2101"

It's quite a bit of patches - feel free to review, comment and send PRs to help me test and get these patches released as quickly as possible.

Thanks!

@e2 This behavior is much better, you can see where I hit ctrl-c, it drops back to the command prompt but the process is in the middle of exiting. It raises an exception at the end, and it seems to be coming out of the lumberjack, but the specs do stop running. Thank you for look at this. Hope this helps!

^CGuard: INT signal, handling inside trap...                                                                                                             |  ETA: 00:02:03
Guard Pry job: handling interrupt
Guard Pry job: no thread, interrupting Guard

RSpec is shutting down and will print the summary report... Interrupt again to force quit.
Guard::RSpec: Interrupted by user. Waiting for RSpec to die...
➜  source_code git:(development) ✗  3/17 |========== 17 ==========>                                                                                                                         |  ETA: 00:02:28
Pending: (Failures listed here are expected and do not affect your suite's status)

  1) items can export items pdf export
     # Temporarily skipped with xit
     # ./spec/features/items_spec.rb:38


Top 3 slowest examples (25.2 seconds, 83.1% of total time):
  items can click export button and walk through modals
    14.92 seconds ./spec/features/items_spec.rb:26
  items appear in proper time periods
    10.28 seconds ./spec/features/items_spec.rb:51
  items can export pdf export
    0.00005 seconds ./spec/features/items_spec.rb:38

Finished in 30.33 seconds (files took 1.14 seconds to load)
3 examples, 0 failures, 1 pending

Randomized with seed 54136

Coverage report generated for RSpec to /Users/justin/dev/source_code/coverage. 1759 / 3324 LOC (52.92%) covered.

➜  source_code git:(development) ✗
10:18:10 - INFO - Inspecting Ruby code style: spec/features/items_spec.rb
Inspecting 1 file
.

1 file inspected, no offenses detected

10:18:11 - INFO - Bye bye...
/Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/device/writer.rb:89:in `close': closed stream (IOError)
    from /Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/device/writer.rb:89:in `close'
    from /Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/logger.rb:140:in `close'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/lib/guard/aruba_adapter.rb:51:in `execute'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/lib/guard/aruba_adapter.rb:20:in `execute!'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/bin/_guard-core:11:in `<main>'

@jetheredge - thanks for testing this.

I won't have time to look into this too soon :(

I'm glad it's more usable though.

Based on your example, RSpec should just stop and Guard should get back to the Pry prompt.

I think the problem here is that Guard traps the INT signal. It shouldn't. It should be only used to kill Pry, but it shouldn't do anything if Pry isn't running (and there are no jobs).

I'd accept a PR for this if someone wants to test. (Basically, the "Guard Pry job: no thread, interrupting Guard" shouldn't be happening - the interrupt should just be ignored in the PryWrapper).

@e2 thanks! I'll take a look at creating a PR next week.

@jetheredge - I think it's enough to replace this line:

https://github.com/guard/guard/blob/c6ab8a0/lib/guard/jobs/pry_wrapper.rb#L108

with just a "return".

Also, Ctrl-C shouldn't exit guard anyway.

@e2 - Thanks for the guidance, this week has been unexpectedly busy, I'll create a PR soon.

We all are, trust me ;)

(If you don't believe me, checkout out the list of issues in Guard -
almost all of them are features).

On Thu, Aug 11, 2016 at 04:10:08AM -0700, Justin Etheredge wrote:

@e2 - Thanks for the guidance, this week has been unexpectedly busy, I'll create a PR soon.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/guard/guard/issues/842#issuecomment-239132345

I apologize, I still have not forgotten about this, it is on my list I've just gotten buried lately. I'm still planning on doing this, it is just taking longer than expected.

I'm buried too. Hopefully I'll get the patches completed and released.

I'm not sure if related, but when I CTRL-C during RSpec I fall back into pry, but guard will never run anything again. I haven't tried debugging it very much. Behavior is the same with and without bundle exec. I tried running with the branches you specified above and it did make a difference where my guard would exit after stopping RSpec.

Any idea? Is it related to this? I'm happy to dig into internals if you don't have an immediate idea about this. We have a lot of slow specs and being able to stop a spec mid-way would save a lot of time. :)

I'm also having this issue on MacOs Sierra.

When I cancel a test, next changes on file doesn't run tests. It stops watching.

I'm having the same issue. Any updates on this?

Same problem here. Using macOS Catalina.