Not listening to file changes, Ubuntu 14.04 #217

lasseebert · 2014-04-23T21:37:26Z

Not sure exactly what is going on, but I am pretty sure my problems started after upgrading to Ubuntu 14.04 (from 13.10).

Short description: Guard does not react to any file changes at all.

Longer description:
My exact setup used to work on ubuntu 13.10. After upgrading no file changes are registered with Guard and Listen.

I have tried the following:

Using this branch: fix + workarounds for editor support on Linux #215
Downgrading Guard and Listen to previous minor version
Using master branch of both Guard and Listen

When running guard with bundle exec guard start --force-polling it listens as expected (but with polling of course).

I have tried to run with --debug but nothing odd shows up.

I am using Ruby 2.1.1 installed with rbenv.

The text was updated successfully, but these errors were encountered:

e2 · 2014-04-24T01:58:26Z

Hi @lasseebert,

Debugging those issues is tough, but thanks for reporting this.

Don't use polling at all on Linux - it doesn't make sense, since rb-inotify should work perfectly
Make sure you have rb-inotify installed and/or in your Gemfile
Temporarily add this branch to your Gemfile (contains fix + workarounds for editor support on Linux #215 + low level debugging output):

gem 'listen', git: 'https://github.com/chronomantic/listen', branch: 'for_debugging'

so e.g. you'd have:

gem 'guard'  # latest released is fine
gem 'guard-bundler'
gem 'listen', git: 'https://github.com/chronomantic/listen', branch: 'for_debugging'

Open a watched file in your editor (e.g. Gemfile if you're using guard-bundler)
Then exit Guard and start with: bundle exec guard --debug
Save the file in the editor and paste what changed
Tell us what editor you're using.
If it didn't help, try using 'touch' on a watched file, e.g: touch Gemfile and paste the results
Afterwards remove the gem 'listen' line from your Gemfile

lasseebert · 2014-04-24T06:47:40Z

Hi @e2

Thanks for the quick response.

I explicit added rb-inotify to the gemfile and bundled, but that did not help.

I added the listen branch, so my gemfile looks like this:

gem 'guard'
gem 'listen', git: 'https://github.com/chronomantic/listen', branch: 'for_debugging'
gem 'guard-rspec'
gem 'rb-inotify'

Then started guard with bundle exec guard --debug.

When I save a watched file (spec/spec_helper in my case) or touch it nothing happens. No output from guard.

This is my guard output, which is outputted when guard starts:

$ bundle exec guard --debug
08:41:51 - DEBUG - Command execution: which notify-send
08:41:51 - DEBUG - Command execution: emacsclient --eval '1' 2> /dev/null || echo 'N/A'
08:41:51 - INFO - Guard is using NotifySend to send notifications.
08:41:51 - INFO - Guard is using TerminalTitle to send notifications.
08:41:51 - DEBUG - Command execution: hash stty
08:41:51 - DEBUG - Guard starts all plugins
08:41:51 - DEBUG - Hook :start_begin executed for Guard::RSpec
08:41:51 - INFO - Guard::RSpec is running
08:41:51 - DEBUG - Hook :start_end executed for Guard::RSpec
08:41:51 - INFO - Guard is now watching at '/home/pulver/code/noder'
08:41:51 - DEBUG - Start interactor
[1] guard(main)>

I'm using Vim.

lasseebert · 2014-04-24T06:49:16Z

For reference, this is my Guardfile:

# A sample Guardfile
# More info at https://github.com/guard/guard#readme

guard :rspec, cmd: "bundle exec rspec" do
  watch(%r{^spec/.+_spec\.rb$})
  watch(%r{^lib/(.+)\.rb$})     { |m| "spec/lib/#{m[1]}_spec.rb" }

  watch('spec/spec_helper.rb')  { "spec" }
  watch('Gemfile.lock')  { "spec" }
end

As stated earlier, guard behaves as expected when using polling.

e2 · 2014-04-24T11:37:28Z

Paste the Gemfile.lock file
Close guard and any apps writing to the project directory and run inotifywait -m -r . from within the project directory
Paste the exact output you're getting, e.g

./ CREATE 4913
./ OPEN 4913
./ ATTRIB 4913
./ CLOSE_WRITE,CLOSE 4913
./ DELETE 4913
./ MOVED_FROM a.rb
./ CREATE a.rb
./ OPEN a.rb
./ MODIFY a.rb
./ CLOSE_WRITE,CLOSE a.rb
./ ATTRIB a.rb
./ ATTRIB a.rb
./ OPEN a.rb
./ CLOSE_NOWRITE,CLOSE a.rb
./ OPEN a.rb
./ CLOSE_NOWRITE,CLOSE a.rb
./ OPEN a.rb
./ ACCESS a.rb
./ CLOSE_NOWRITE,CLOSE a.rb
./ OPEN a.rb
./ CLOSE_NOWRITE,CLOSE a.rb

(That's me editing a file in Vim).

If you're getting output like above, then next download this: https://gist.github.com/e2/11251178 into your project directory and run as bundle exec ruby test_inotify.rb.

Then edit a file and paste the output.

Then we should at least know exactly what's failing...

thibaudgg · 2014-04-24T12:11:49Z

awesome, thanks!

lasseebert · 2014-04-24T20:53:39Z

Thanks @e2, you led me in the right direction.

Running inotifywait -m -r . gave me this output:

$ inotifywait -m -r .
Setting up watches.  Beware: since -r was given, this may take a while!
Failed to watch .; upper limit on inotify watches reached!
Please increase the amount of inotify watches allowed per user via `/proc/sys/fs/inotify/max_user_watches'.

So i edited the max_user_watches file and increased number of watches per user from 8196 to 81960. Now Guard runs as expected again! :)
So now I know what was the issue, now I just need to figure out why my limit was reached or if it is ok to allow 80k watches.

For my sake this issue can be closed now, but I'm keeping it open in case some of this should be in the README.

e2 · 2014-04-25T04:21:31Z

Listen was supposed to show that message and exit (fixed in #218).

e2 · 2014-04-25T04:39:21Z

@lasseebert, could be dropbox or some file-indexing utility that's eating up those watches - but that's nothing to worry about, since even dropbox tells people to set it to 100,000.

Listen should have shown an error with a link to this:
https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers

lasseebert · 2014-04-25T07:13:23Z

@e2, after upgrading to Listen 2.7.2, I get the warning:

$ guard
09:10:13 - INFO - Guard is using NotifySend to send notifications.
09:10:13 - INFO - Guard is using TerminalTitle to send notifications.
09:10:13 - INFO - Guard::RSpec is running
09:10:13 - INFO - Guard is now watching at '/home/pulver/code/noder'
FATAL: Listen error: unable to monitor directories for changes.
Please head to https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers
for information on how to solve this issue.
[1] guard(main)>

Thanks

e2 · 2014-04-25T08:20:27Z

Thanks for reporting this and taking the time to do so, @lasseebert !

lasseebert · 2014-04-25T08:22:34Z

I thank you :) Keep up the great work.

dima4p · 2014-05-02T13:49:35Z

I have the issue with kate.
Whent I touch or save in vim I see:
17:32:47 - DEBUG - Stop interactor
17:32:47 - DEBUG - Hook :run_on_modifications_begin executed for Guard::RSpec
17:32:47 - INFO - Running: spec/controllers/users_controller_spec.rb
and the tests run. But at save in kate there is other output:
17:32:38 - DEBUG - Stop interactor
17:32:38 - DEBUG - Trying to run Guard::RSpec#run_on_additions with ["spec/controllers/users_controller_spec.rb"]
17:32:38 - DEBUG - Trying to run Guard::RSpec#run_on_changes with ["spec/controllers/users_controller_spec.rb"]
17:32:38 - DEBUG - Trying to run Guard::RSpec#run_on_change with ["spec/controllers/users_controller_spec.rb"]
17:32:38 - DEBUG - Start interactor
and no test is ran.

e2 · 2014-05-02T14:10:42Z

@dima4p - in your case, guard is not detecting Kate's saving as a modification, but as adding a new file (which guard-rspec ignores).

Upgrade your listen gem version to: 2.7.3 and restart guard - and let me know if that helped.

If that still doesn't work, run guard with:

LISTEN_GEM_DEBUGGING=1 bundle exec guard

... so I kind find out what Kate is doing different, thanks!

dima4p · 2014-05-02T14:25:31Z

$ LISTEN_GEM_DEBUGGING=1 bundle exec guard
18:19:09 - INFO - Guard is using NotifySend to send notifications.
18:19:09 - INFO - Guard is using TerminalTitle to send notifications.
18:19:09 - INFO - Guard::RSpec is running
18:19:09 - INFO - Guard is now watching at '/home/dima/devel/www/project'
[1] guard(main)> I, [2014-05-02T18:19:20.086554 #28698] INFO -- : listen: inotify event: [:delete]: users_controller_spec.rb~
I, [2014-05-02T18:19:20.086926 #28698] INFO -- : listen: inotify event: [:create]: qt_temp.p22583
I, [2014-05-02T18:19:20.087263 #28698] INFO -- : listen: inotify event: [:close_write, :close]: qt_temp.p22583
I, [2014-05-02T18:19:20.087381 #28698] INFO -- : listen: inotify event: [:moved_from, :move]: qt_temp.p22583
I, [2014-05-02T18:19:20.087478 #28698] INFO -- : listen: inotify event: [:moved_to, :move]: users_controller_spec.rb~
I, [2014-05-02T18:19:20.087564 #28698] INFO -- : listen: inotify event: [:attrib]: users_controller_spec.rb~
I, [2014-05-02T18:19:20.121224 #28698] INFO -- : listen: inotify event: [:create]: users_controller_spec.rbo22583.new
I, [2014-05-02T18:19:20.121774 #28698] INFO -- : listen: inotify event: [:attrib]: users_controller_spec.rbo22583.new
I, [2014-05-02T18:19:20.122041 #28698] INFO -- : listen: inotify event: [:close_write, :close]: users_controller_spec.rbo22583.new
I, [2014-05-02T18:19:20.172428 #28698] INFO -- : listen: inotify event: [:close_write, :close]: users_controller_spec.rbo22583.new
I, [2014-05-02T18:19:20.172897 #28698] INFO -- : listen: inotify event: [:moved_from, :move]: users_controller_spec.rbo22583.new
I, [2014-05-02T18:19:20.173024 #28698] INFO -- : listen: inotify event: [:moved_to, :move]: users_controller_spec.rb
I, [2014-05-02T18:19:20.288534 #28698] INFO -- : listen: raw changes: [[nil, "/home/dima/devel/www/project/spec/controllers/qt_temp.p22583"], [:modified, "/home/dima/devel/www/project/spec/controllers/users_controller_spec.rb~"], [nil, "/home/dima/devel/www/project/spec/controllers/users_controller_spec.rbo22583.new"], [:added, "/home/dima/devel/www/project/spec/controllers/users_controller_spec.rb"]]
I, [2014-05-02T18:19:20.288666 #28698] INFO -- : listen: final changes: {:modified=>["/home/dima/devel/www/project/spec/controllers/users_controller_spec.rb~"], :added=>["/home/dima/devel/www/project/spec/controllers/users_controller_spec.rb"], :removed=>[]}

e2 · 2014-05-02T16:11:33Z

@dima4p - thanks so much! I can see what's wrong now.

Could you check to see if this branch fixes everything?:

gem 'listen', github: 'guard/listen', branch: 'kate_editing_tmp_ignores'

(bundle install, restart guard, etc.)

e2 · 2014-05-02T16:34:39Z

@dima4p - sorry for the mess with issues, let's move the discussion to where it should be: #180

Kulgar · 2014-08-21T15:52:54Z

Hi,

I have the same issue as described in the first post of this thread. I've done everything until this:

Paste the Gemfile.lock file
Close guard and any apps writing to the project directory and run inotifywait -m -r . from within the project directory

inotifywait seem to work properly. But, the test_inotify.rb script does not work, here is my output when I interrupt it:

/home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/celluloid-0.15.2/lib/celluloid/thread_handle.rb:37:in `sleep': Interrupt
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/celluloid-0.15.2/lib/celluloid/thread_handle.rb:37:in `wait'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/celluloid-0.15.2/lib/celluloid/thread_handle.rb:37:in `block in join'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/celluloid-0.15.2/lib/celluloid/thread_handle.rb:37:in `synchronize'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/celluloid-0.15.2/lib/celluloid/thread_handle.rb:37:in `join'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/celluloid-0.15.2/lib/celluloid/actor.rb:129:in `join'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/celluloid-0.15.2/lib/celluloid.rb:162:in `block (2 levels) in shutdown'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/celluloid-0.15.2/lib/celluloid.rb:160:in `each'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/celluloid-0.15.2/lib/celluloid.rb:160:in `block in shutdown'
    from /home/regis/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/timeout.rb:91:in `block in timeout'
    from /home/regis/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/timeout.rb:35:in `block in catch'
    from /home/regis/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/timeout.rb:35:in `catch'
    from /home/regis/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/timeout.rb:35:in `catch'
    from /home/regis/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/timeout.rb:106:in `timeout'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/celluloid-0.15.2/lib/celluloid.rb:144:in `shutdown'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/celluloid-0.15.2/lib/celluloid.rb:131:in `block in register_shutdown'
/home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/native/flags.rb:74:in `block in to_mask': Interrupt
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/native/flags.rb:74:in `each'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/native/flags.rb:74:in `inject'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/native/flags.rb:74:in `to_mask'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/watcher.rb:67:in `initialize'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:190:in `new'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:190:in `watch'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:204:in `watch'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:198:in `block in watch'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:194:in `each'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:194:in `watch'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:198:in `block in watch'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:194:in `each'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:194:in `watch'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:198:in `block in watch'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:194:in `each'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:194:in `watch'
    from /home/regis/.rvm/gems/ruby-2.1.2@canvas/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:198:in `block in watch'
    from ./test_inotify.rb:16:in `block in <main>'
    from ./test_inotify.rb:15:in `tap'
    from ./test_inotify.rb:15:in `<main>'

The each / watch / block in watch part is repeating itself a looot (as if there is an infinite loop or something... )
I use guard version 2.6.1, listen version 2.7.0 and rb-inotify version 0.9.5.
My Ubuntu is version 14.04. As @lasseebert I did the upgrade recently and everything worked fine before. I also already changed /proc/sys/fs/inotify/max_user_watches - but no good.
Also, I have the exact same issue with guard version 1.8 and listen version 1.3...

I'm quite stuck with this issue :) thanks. ;)

--- [ Edit ] after doing some investigations it seems that guard/listen is no longer ignoring folders such as .git, node_modules, tmp and others... Where could it come frome?

--- Did a little bit more investigations, the bug seems to be related to my project somehow, my project is a fork of the Canvas Lms open source project, and when I run guard in the master branch (without any modifications) it just never enters the interactive mode as if it is loading too much files (but in the stable branch, it works). I've posted a message on their google group, I'll wait and see if they answer and give you the feedback here as it may reveal a bug.

Kulgar · 2014-08-26T13:15:50Z

Ok I've found the problem:

A symlink file was linking to the root folder of my application (don't ask me why, it is an open source application). Thus, guard/listen was following this file again and again, creating an infinite loop.

Could that be considered as an issue because it easily creates an infinite loop?

e2 · 2014-09-14T20:10:14Z

Thanks @Kulgar for the info - it could be a problem with rb-inotify (which resolves symlinks as it walks the tree AFAIR) or how Listen uses it.

(Symlinks are still a work in progress: #25)

Could you open up a new issue with an example of the symlink? (Just so you get notified when it's fixed, and move the discussion there, etc.)

Kulgar · 2014-09-15T21:02:21Z

@e2 Done 😄

wasimgit · 2016-09-04T15:12:09Z

I got a simple solution,

Run this cammand in your Ubuntu 14.04 terminal

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers

That is all.

e2 mentioned this issue Apr 25, 2014

fix + workarounds for editor support on Linux #215

Merged

lasseebert closed this as completed Apr 25, 2014

e2 mentioned this issue Apr 27, 2014

Specs are not running after file change guard/guard-rspec#262

Closed

e2 mentioned this issue May 2, 2014

run_on_modifications no longer firing for Kate on Linux. #180

Closed

Kulgar mentioned this issue Sep 15, 2014

Detect symlinks with infinite loops #259

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Not listening to file changes, Ubuntu 14.04 #217

Not listening to file changes, Ubuntu 14.04 #217

lasseebert commented Apr 23, 2014

e2 commented Apr 24, 2014

lasseebert commented Apr 24, 2014

lasseebert commented Apr 24, 2014

e2 commented Apr 24, 2014

thibaudgg commented Apr 24, 2014

lasseebert commented Apr 24, 2014

e2 commented Apr 25, 2014

e2 commented Apr 25, 2014

lasseebert commented Apr 25, 2014

e2 commented Apr 25, 2014

lasseebert commented Apr 25, 2014

dima4p commented May 2, 2014

e2 commented May 2, 2014

dima4p commented May 2, 2014

e2 commented May 2, 2014

e2 commented May 2, 2014

Kulgar commented Aug 21, 2014

Kulgar commented Aug 26, 2014

e2 commented Sep 14, 2014

Kulgar commented Sep 15, 2014

wasimgit commented Sep 4, 2016 •

edited

Loading

Not listening to file changes, Ubuntu 14.04 #217

Not listening to file changes, Ubuntu 14.04 #217

Comments

lasseebert commented Apr 23, 2014

e2 commented Apr 24, 2014

lasseebert commented Apr 24, 2014

lasseebert commented Apr 24, 2014

e2 commented Apr 24, 2014

thibaudgg commented Apr 24, 2014

lasseebert commented Apr 24, 2014

e2 commented Apr 25, 2014

e2 commented Apr 25, 2014

lasseebert commented Apr 25, 2014

e2 commented Apr 25, 2014

lasseebert commented Apr 25, 2014

dima4p commented May 2, 2014

e2 commented May 2, 2014

dima4p commented May 2, 2014

e2 commented May 2, 2014

e2 commented May 2, 2014

Kulgar commented Aug 21, 2014

Kulgar commented Aug 26, 2014

e2 commented Sep 14, 2014

Kulgar commented Sep 15, 2014

wasimgit commented Sep 4, 2016 • edited Loading

wasimgit commented Sep 4, 2016 •

edited

Loading