guard / rb-inotify Goto Github PK
View Code? Open in Web Editor NEWA thorough inotify wrapper for Ruby using FFI.
License: MIT License
A thorough inotify wrapper for Ruby using FFI.
License: MIT License
This will make it show up on rubygems.org. I'm doing due diligence on our gems and need to find out the licenses for all the gems. Having it show up on rubygems.org cuts out the step of having to go to the github repo.
notifier will continue notifying
EINTR is unhandled, notifier crashes (when running with ajkovar's patch, otherwise it hits the unresolved name)
maybe this is supposed to be handled by the user of the library? if so, maybe rb-inotify should raise Errno::EINTR instead of rescueing and later raising an rb-inotify specific error.
not sure how to attach a pull request, so here's a link to my fork: https://github.com/ozzloy/rb-inotify
edit
here's a pull request to the fork with a fix my issue depends on.
ajkovar#1
/usr/local/lib/ruby/gems/1.9.1/gems/rb-inotify-0.8.6/lib/rb-inotify/notifier.rb:193:in `block in watch': invalid byte sequence in UTF-8 (ArgumentError)
from /usr/local/lib/ruby/gems/1.9.1/gems/rb-inotify-0.8.6/lib/rb-inotify/notifier.rb:192:in `each'
from /usr/local/lib/ruby/gems/1.9.1/gems/rb-inotify-0.8.6/lib/rb-inotify/notifier.rb:192:in `watch'
from /usr/local/lib/ruby/gems/1.9.1/gems/rb-inotify-0.8.6/lib/rb-inotify/notifier.rb:194:in `block in watch'
When a new Watcher
is created, it adds itself to the notifiers hash (of watchers) using this:
@notifier.watchers[@id] = self
However, when the same watcher is now #close
d, it does not delete itself from the hash.
This causes the watcher to never get GC'ed because the notifier hash will always contain a reference to it. Now a sequence of constantly changing watchers will result in several "leaked" objects.
Similarly when a Notifier
is #close
d , it does not empty its Hash. It simply closes the underlying fd and returns.
Both of these fixes should be trivial (unless I'm missing something).
Hi!
Where can I find a rdoc? rdoc.info didn't quite work...
I recently updated a Rails 5.1 bundle on systems running Centos 6 and RHEL7 and then my DelayedJob workers would abort when I tried to start the commands.
$ bin/delayed_job start
pid-file for killed process 22998 found (/rails_app/pids/delayed_job.pid), deleting.
delayed_job: process with pid 16048 started.
Aborted (core dumped)
$
I chased the bundle update down gem by gem and determined that bundle update spring-watcher-listen
was causing the Aborted on DelayedJob startup.
There are issues Segfault on macOS with ffi > 1.9.21 and SIGABRT on Centos/RHEL 6+7 open or FFI for this, but it may make sense to modify the gemspec to exclude ffi versions 1.9.22 and 1.9.23.
I also just tried a fresh rails new testapp
and ffi locks at 1.9.23, so any new Rails 5.1.x app generated on Centos, RHEL, and possibly MacOS (not confirmed) could be affected.
Changing spec.add_dependency "ffi", "~> 1.0"
to spec.add_dependency "ffi", "~> 1.0", '!= 1.9.22', '!= 1.9.23'
solved the issue for me locally.
I hit a stack level too deep error while running jekyll in the jekyll-docker container (envygeeks/jekyll-docker#212), which uses musl as its libc. They said that the bug belonged here. Assuming that rb-inotify owns the offending thread, I think you should be able to set the stack size at thread creation time
We use jekyll/jekyll:pages
for local testing of the documentation of our project. Recently, local builds started failing with a stack overflow.
It reproduces with the latest image:
$ docker pull jekyll/jekyll:pages
pages: Pulling from jekyll/jekyll
...
Digest: sha256:0c0c3585c91bbb07328d1f32a443d2ce2a92e3ddf5e0ce5d385dd91c4d96125a
Status: Downloaded newer image for jekyll/jekyll:pages
I tried setting the ulimit and Ruby stack size:
docker run ... --ulimit stack=64000000 -e RUBY_THREAD_VM_STACK_SIZE=64000000 ...
but it didn't seem to help.
I noticed that the image was compiled with musl as its libc and found this in their docs: https://wiki.musl-libc.org/functional-differences-from-glibc.html#Thread_stack_size It sounds like muslc uses an unusually small stack and it is not configurable via ulimit or env var.
This seems to reproduce on most (but not all) of my colleagues machines; it should be as simple as doing this:
git clone https://github.com/projectcalico/calico.git
cd calico
make serve
I was testing on an Ubuntu 17.10 VM.
$ make serve
docker run --rm -ti -e JEKYLL_UID=`id -u` -p 4000:4000 -v $PWD:/srv/jekyll jekyll/jekyll:pages jekyll serve --incremental --config _config.yml
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux-musl]
Configuration file: _config.yml
Source: /srv/jekyll
Destination: /srv/jekyll/_site
Incremental build: enabled
Generating...
GitHub Metadata: No GitHub API authentication could be found. Some fields may be missing or have incorrect data.
done in 39.923 seconds.
Traceback (most recent call last):
186: from /usr/gem/bin/jekyll:23:in `<main>'
185: from /usr/gem/bin/jekyll:23:in `load'
184: from /usr/gem/gems/jekyll-3.6.2/exe/jekyll:15:in `<top (required)>'
183: from /usr/gem/gems/mercenary-0.3.6/lib/mercenary.rb:19:in `program'
182: from /usr/gem/gems/mercenary-0.3.6/lib/mercenary/program.rb:42:in `go'
181: from /usr/gem/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `execute'
180: from /usr/gem/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `each'
179: from /usr/gem/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `block in execute'
... 174 levels...
4: from /usr/gem/gems/rb-inotify-0.9.10/lib/rb-inotify/notifier.rb:190:in `new'
3: from /usr/gem/gems/rb-inotify-0.9.10/lib/rb-inotify/watcher.rb:67:in `initialize'
2: from /usr/gem/gems/rb-inotify-0.9.10/lib/rb-inotify/native/flags.rb:79:in `to_mask'
1: from /usr/gem/gems/rb-inotify-0.9.10/lib/rb-inotify/native/flags.rb:79:in `inject'
/usr/gem/gems/rb-inotify-0.9.10/lib/rb-inotify/native/flags.rb:79:in `each': stack level too deep (SystemStackError)
Makefile:27: recipe for target 'serve' failed
make: *** [serve] Error 1
No crash, page should be served as normal.
I honestly don't know whether it's compass, sass, ruby, rb-inotify bug or something I'm screwing on my side, but every few minutes compass watch
crashes throwing these:
Exception on line ["120"] of /usr/local/rvm/gems/ruby-1.9.3-p448/gems/rb-inotify-0.9.2/lib/rb-inotify/event.rb: inotify event queue has overflowed.
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/rb-inotify-0.9.2/lib/rb-inotify/event.rb:100:in `new'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/rb-inotify-0.9.2/lib/rb-inotify/event.rb:100:in `consume'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/rb-inotify-0.9.2/lib/rb-inotify/notifier.rb:277:in `read_events'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/rb-inotify-0.9.2/lib/rb-inotify/notifier.rb:238:in `process'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/rb-inotify-0.9.2/lib/rb-inotify/notifier.rb:221:in `run'
/usr/local/rvm/gems/ruby-1.9.3-p448/gems/listen-0.7.3/lib/listen/adapters/linux.rb:47:in `block in start'
All gems installed are:
breakpoint (2.0.7)
chunky_png (1.2.8)
compass (0.13.alpha.4, 0.12.2)
ffi (1.9.0)
fssm (0.2.10)
listen (1.1.6, 0.7.3)
rb-fsevent (0.9.3)
rb-inotify (0.9.2, 0.9.1)
rb-kqueue (0.2.0)
sass (3.3.0.alpha.253, 3.2.10)
stitch (0.1.7.beta.3)
susy (1.0.9)
Any clues?
For:
require 'rb-inotify'
notifier = INotify::Notifier.new
notifier.watch(__FILE__, :modify) { puts "I was changed " }
notifier.run
I get a single notify event when I save the file and none after no matter how I change the file
for:
require 'rb-inotify'
notifier = INotify::Notifier.new
notifier.watch('.', :modify) { puts "I was changed " }
notifier.run
I get notify events properly, is there a caveat / bug around single file watching?
Hi
I've been using your gem, but it's not working quite as I would expect.
It seems that I have to reregister the watcher whenever an event has occurred. So running notifier.run will loop forever, but only handle each registered event once. To continuously handle events I have to use notifier.process in a loop and run notifier.watch after process, see example below. If I omit the call to watch() in the loop, the handler will only be called the first time the file is modified.
I don't know if this is intended behaviour or not, at least I don't think it is reflected in the readme.
Thanks,
Petur
require 'rb-inotify'
handler = Proc.new { puts "handle" }
notifier = INotify::Notifier.new
notifier.watch("./file.txt", :modify, &handler)
loop {
notifier.process
notifier.watch("./file.txt", :modify, &handler)
}
Thank you for this tool.
I am struggling to correctly understand the documentation of #watch
. It says
Watches a file or directory for changes, calling the callback when there are. This is only activated once #process or #run is called.
What exactly is activated once #process
or #run
is called? The watchers or the callbacks? For example if I call notifier.watch("path/to/foo.txt", :delete_self) {puts "foo.txt was deleted!"}
then the file gets deleted and then I call notifier.process
. Will the callback be called or was the watcher not yet activated when I processed the available events?
This is a issue discovered and discussed in this thread: guard/listen#155
I'm using kubuntu 13.10 and SublimeText3 (build 3056 but the same issue occurs in previous builds). It seems like rb-inotify
generates different events when listening file and directory. Following code:
require 'rb-inotify'
notifier = INotify::Notifier.new
notifier.watch('/home/marek/git/rails/air/spec/models/appliance_spec.rb', :attrib) do |event|
puts "#{event.flags} is now in #{event.absolute_name}!"
end
notifier.run
generates:
[:attrib] is now in /home/marek/git/rails/air/spec/models/appliance_spec.rb!
[:ignored] is now in /home/marek/git/rails/air/spec/models/appliance_spec.rb!
while saving file using Sublimetext3. But following code:
require 'rb-inotify'
EVENTS = [:recursive, :attrib, :create, :delete, :move, :close_write]
notifier = INotify::Notifier.new
notifier.watch('/home/marek/git/rails/air', *EVENTS) do |event|
puts "#{event.flags} is now in #{event.absolute_name}!"
end
notifier.run
generates:
[:create] is now in /home/marek/git/rails/air/spec/models/.subleb0.tmp!
[:attrib] is now in /home/marek/git/rails/air/spec/models/.subleb0.tmp!
[:close_write, :close] is now in /home/marek/git/rails/air/spec/models/.subleb0.tmp!
[:attrib] is now in /home/marek/git/rails/air/spec/models/.subleb0.tmp!
[:moved_from, :move] is now in /home/marek/git/rails/air/spec/models/.subleb0.tmp!
[:moved_to, :move] is now in /home/marek/git/rails/air/spec/models/appliance_spec.rb!
Something is wrong with version 0.8.3.
If you install it, you can not use it, since file permissions are 640 and not 644.
use native read calls to work around JVM's current lack of real file descriptors
I don't know, if you can do anything about that. But wanted to let you know.
I get the following error:
Could not find rb-inotify.gem (rubygems:rb-inotify:0.9.6).
Searched in the following locations:
http://rubygems-proxy.torquebox.org/releases/rubygems/rb-inotify/0.9.6/rb-inotify-0.9.6.gem
When using Ruby 2.7.0, Rails 6.1.2.1, I get the following warning:
.../gems/rb-inotify-0.10.0/lib/rb-inotify/watcher.rb:66: warning: rb_safe_level will be removed in Ruby 3.0
Hello,
rb-inotify
is used from Rails.
and rb-inotify
RPM package is manged by Fedora Project.
https://admin.fedoraproject.org/pkgdb/package/rpms/rubygem-rb-inotify/
So, I want to add unit tests to test rb-inotify
.
And I guess that nowadays minitest
is best choice for that.
How do you think?
I am going to send pull-request as my proposal soon.
Hi,
I create a watcher in ftp server to watch a folder with :all_events. when I upload a file. and log the event name. and the result is:
I, [2013-10-21T04:11:59.185854 #314] INFO -- : text.xml is create
I, [2013-10-21T04:11:59.186218 #314] INFO -- : text.xml is modify
I, [2013-10-21T04:11:59.407435 #314] INFO -- : text.xml is modify
it's a normal behaviour when a file created and triggered 3 events in a row?
JRuby shows Thread termination exceptions with 0.10.0. Note that whatever exception occurs the command completes and I notice no problems other than the massive backtrace. I also notice something when performing a db:migrate.
If I had to guess I would say we (jruby) maybe is throwing the wrong exception? We are also trying to dig deeper on cause but you may know what was changed in rb-inotify which may explain this.
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/bin/jruby -S rails generate scaffold person name:string
invoke active_record
create db/migrate/20181219200006_create_people.rb
create app/models/person.rb
invoke test_unit
create test/models/person_test.rb
create test/fixtures/people.yml
invoke resource_route
route resources :people
invoke scaffold_controller
create app/controllers/people_controller.rb
invoke erb
create app/views/people
create app/views/people/index.html.erb
create app/views/people/edit.html.erb
create app/views/people/show.html.erb
create app/views/people/new.html.erb
create app/views/people/_form.html.erb
invoke test_unit
create test/controllers/people_controller_test.rb
create test/system/people_test.rb
invoke helper
create app/helpers/people_helper.rb
invoke test_unit
invoke jbuilder
create app/views/people/index.json.jbuilder
create app/views/people/show.json.jbuilder
create app/views/people/_person.json.jbuilder
invoke assets
invoke coffee
create app/assets/javascripts/people.coffee
invoke scss
create app/assets/stylesheets/people.scss
invoke scss
create app/assets/stylesheets/scaffolds.scss
E, [2018-12-19T14:00:07.226180 #3263] ERROR -- : run() in thread failed: :\n sun.nio.ch.SelectorImpl.keys(SelectorImpl.java:68)
org.jruby.util.io.SelectorPool.put(SelectorPool.java:88)
org.jruby.util.io.SelectExecutor.selectEnd(SelectExecutor.java:59)
org.jruby.util.io.SelectExecutor.go(SelectExecutor.java:44)
org.jruby.RubyIO.select(RubyIO.java:3549)
org.jruby.RubyKernel.select(RubyKernel.java:665)
org.jruby.RubyKernel$INVOKER$s$0$3$select.call(RubyKernel$INVOKER$s$0$3$select.gen)
org.jruby.internal.runtime.methods.JavaMethod$JavaMethodN.call(JavaMethod.java:797)
org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:199)
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:344)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:170)
org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:317)
org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:86)
org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:171)
org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:158)
org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:199)
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:344)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:170)
org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:317)
org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:80)
org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:138)
org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:125)
org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:191)
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:323)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:139)
org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:346)
org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:80)
org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:138)
org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:125)
org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:191)
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:323)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:139)
org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:346)
org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
org.jruby.ir.interpreter.Interpreter.INTERPRET_BLOCK(Interpreter.java:128)
org.jruby.runtime.MixedModeIRBlockBody.commonYieldPath(MixedModeIRBlockBody.java:151)
org.jruby.runtime.IRBlockBody.yieldSpecific(IRBlockBody.java:89)
org.jruby.runtime.Block.yieldSpecific(Block.java:134)
org.jruby.ext.thread.Mutex.synchronize(Mutex.java:158)
org.jruby.ext.thread.Mutex$INVOKER$i$0$0$synchronize.call(Mutex$INVOKER$i$0$0$synchronize.gen)
org.jruby.internal.runtime.methods.JavaMethod$JavaMethodZeroBlock.call(JavaMethod.java:537)
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:301)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:82)
org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:89)
org.jruby.ir.instructions.CallBase.interpret(CallBase.java:537)
org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:362)
org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:80)
org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:138)
org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:125)
org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:191)
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:323)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:139)
org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:346)
org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:80)
org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:138)
org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:125)
org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:191)
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:323)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:139)
org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:346)
org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
org.jruby.ir.interpreter.Interpreter.INTERPRET_BLOCK(Interpreter.java:128)
org.jruby.runtime.MixedModeIRBlockBody.commonYieldPath(MixedModeIRBlockBody.java:151)
org.jruby.runtime.IRBlockBody.call(IRBlockBody.java:79)
org.jruby.runtime.Block.call(Block.java:124)
org.jruby.RubyProc.call(RubyProc.java:286)
org.jruby.RubyProc.call(RubyProc.java:266)
org.jruby.RubyProc$INVOKER$i$0$0$call.call(RubyProc$INVOKER$i$0$0$call.gen)
org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:195)
org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:191)
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:323)
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:139)
org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:346)
org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
org.jruby.ir.interpreter.Interpreter.INTERPRET_BLOCK(Interpreter.java:128)
org.jruby.runtime.MixedModeIRBlockBody.commonYieldPath(MixedModeIRBlockBody.java:151)
org.jruby.runtime.IRBlockBody.call(IRBlockBody.java:79)
org.jruby.runtime.Block.call(Block.java:124)
org.jruby.RubyProc.call(RubyProc.java:286)
org.jruby.RubyProc.call(RubyProc.java:270)
org.jruby.internal.runtime.RubyRunnable.run(RubyRunnable.java:105)
java.lang.Thread.run(Thread.java:748)\n\ncalled from:\n /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/forwardable.rb:229:in `start'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/listener.rb:68:in `block in Listener'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/fsm.rb:121:in `instance_eval'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/fsm.rb:121:in `call'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/fsm.rb:91:in `transition_with_callbacks!'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/fsm.rb:57:in `transition'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/listener.rb:91:in `start'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/evented_file_update_checker.rb:96:in `boot!'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/evented_file_update_checker.rb:67:in `initialize'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/i18n_railtie.rb:61:in `initialize_i18n'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/i18n_railtie.rb:19:in `block in Railtie'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/lazy_load_hooks.rb:69:in `block in execute_hook'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/lazy_load_hooks.rb:62:in `with_execution_control'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/lazy_load_hooks.rb:67:in `execute_hook'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/lazy_load_hooks.rb:52:in `block in run_load_hooks'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/lazy_load_hooks.rb:51:in `each'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/lazy_load_hooks.rb:51:in `run_load_hooks'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/application/finisher.rb:75:in `block in Finisher'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/initializable.rb:32:in `instance_exec'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/initializable.rb:32:in `run'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/initializable.rb:61:in `block in run_initializers'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:228:in `block in tsort_each'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:350:in `block in each_strongly_connected_component'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:431:in `each_strongly_connected_component_from'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:349:in `block in each_strongly_connected_component'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:347:in `call'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:347:in `each_strongly_connected_component'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:226:in `tsort_each'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:205:in `tsort_each'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/initializable.rb:60:in `run_initializers'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/application.rb:361:in `initialize!'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/frogger/config/environment.rb:5:in `<main>'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in `block in require'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in `block in require'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:257:in `load_dependency'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in `require'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/application.rb:1:in `(root)'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/application.rb:337:in `require_environment!'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/command/actions.rb:18:in `require_application_and_environment!'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/commands/generate/generate_command.rb:21:in `perform'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/command/base.rb:65:in `perform'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/command.rb:46:in `<main>'
bin/rails:4:in `require'
bin/rails:4:in `<main>'
warning: thread "Ruby-0-Thread-2: /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/internals/thread_pool.rb:6" terminated with exception (report_on_exception is true):
java.nio.channels.ClosedSelectorException
at sun.nio.ch.SelectorImpl.keys(SelectorImpl.java:68)
at org.jruby.util.io.SelectorPool.put(SelectorPool.java:88)
at org.jruby.util.io.SelectExecutor.selectEnd(SelectExecutor.java:59)
at org.jruby.util.io.SelectExecutor.go(SelectExecutor.java:44)
at org.jruby.RubyIO.select(RubyIO.java:3549)
at org.jruby.RubyKernel.select(RubyKernel.java:665)
at org.jruby.RubyKernel$INVOKER$s$0$3$select.call(RubyKernel$INVOKER$s$0$3$select.gen)
at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodN.call(JavaMethod.java:797)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:199)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:344)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:170)
at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:317)
at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
at org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:86)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:171)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:158)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:199)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:344)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:170)
at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:317)
at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
at org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:80)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:138)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:125)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:191)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:323)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:139)
at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:346)
at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
at org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:80)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:138)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:125)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:191)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:323)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:139)
at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:346)
at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
at org.jruby.ir.interpreter.Interpreter.INTERPRET_BLOCK(Interpreter.java:128)
at org.jruby.runtime.MixedModeIRBlockBody.commonYieldPath(MixedModeIRBlockBody.java:151)
at org.jruby.runtime.IRBlockBody.yieldSpecific(IRBlockBody.java:89)
at org.jruby.runtime.Block.yieldSpecific(Block.java:134)
at org.jruby.ext.thread.Mutex.synchronize(Mutex.java:158)
at org.jruby.ext.thread.Mutex$INVOKER$i$0$0$synchronize.call(Mutex$INVOKER$i$0$0$synchronize.gen)
at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodZeroBlock.call(JavaMethod.java:537)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:301)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:82)
at org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:89)
at org.jruby.ir.instructions.CallBase.interpret(CallBase.java:537)
at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:362)
at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
at org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:80)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:138)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:125)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:191)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:323)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:139)
at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:346)
at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
at org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:80)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:138)
at org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:125)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:191)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:323)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:139)
at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:346)
at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
at org.jruby.ir.interpreter.Interpreter.INTERPRET_BLOCK(Interpreter.java:128)
at org.jruby.runtime.MixedModeIRBlockBody.commonYieldPath(MixedModeIRBlockBody.java:151)
at org.jruby.runtime.IRBlockBody.call(IRBlockBody.java:79)
at org.jruby.runtime.Block.call(Block.java:124)
at org.jruby.RubyProc.call(RubyProc.java:286)
at org.jruby.RubyProc.call(RubyProc.java:266)
at org.jruby.RubyProc$INVOKER$i$0$0$call.call(RubyProc$INVOKER$i$0$0$call.gen)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:195)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:191)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:323)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:139)
at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:346)
at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
at org.jruby.ir.interpreter.Interpreter.INTERPRET_BLOCK(Interpreter.java:128)
at org.jruby.runtime.MixedModeIRBlockBody.commonYieldPath(MixedModeIRBlockBody.java:151)
at org.jruby.runtime.IRBlockBody.call(IRBlockBody.java:79)
at org.jruby.runtime.Block.call(Block.java:124)
at org.jruby.RubyProc.call(RubyProc.java:286)
at org.jruby.RubyProc.call(RubyProc.java:270)
at org.jruby.internal.runtime.RubyRunnable.run(RubyRunnable.java:105)
at java.lang.Thread.run(Thread.java:748)
E, [2018-12-19T14:00:07.239949 #3263] ERROR -- : run() in thread failed: closed stream:\n org/jruby/RubyIO.java:3549:in `select'
org/jruby/RubyKernel.java:665:in `select'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:306:in `readpartial'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:279:in `read_events'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:252:in `process'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:229:in `block in run'
org/jruby/ext/thread/Mutex.java:158:in `synchronize'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:226:in `run'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/adapter/linux.rb:39:in `_run'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/adapter/base.rb:78:in `block in start'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/internals/thread_pool.rb:6:in `block in add'\n\ncalled from:\n /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/forwardable.rb:229:in `start'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/listener.rb:68:in `block in Listener'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/fsm.rb:121:in `instance_eval'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/fsm.rb:121:in `call'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/fsm.rb:91:in `transition_with_callbacks!'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/fsm.rb:57:in `transition'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/listener.rb:91:in `start'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/evented_file_update_checker.rb:96:in `boot!'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/evented_file_update_checker.rb:67:in `initialize'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/application/finisher.rb:166:in `block in Finisher'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/initializable.rb:32:in `instance_exec'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/initializable.rb:32:in `run'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/initializable.rb:61:in `block in run_initializers'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:228:in `block in tsort_each'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:350:in `block in each_strongly_connected_component'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:431:in `each_strongly_connected_component_from'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:349:in `block in each_strongly_connected_component'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:347:in `call'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:347:in `each_strongly_connected_component'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:226:in `tsort_each'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/stdlib/tsort.rb:205:in `tsort_each'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/initializable.rb:60:in `run_initializers'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/application.rb:361:in `initialize!'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/frogger/config/environment.rb:5:in `<main>'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in `block in require'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in `block in require'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:257:in `load_dependency'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/activesupport-5.2.2/lib/active_support/dependencies.rb:291:in `require'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/application.rb:1:in `(root)'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/application.rb:337:in `require_environment!'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/command/actions.rb:18:in `require_application_and_environment!'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/commands/generate/generate_command.rb:21:in `perform'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/command/base.rb:65:in `perform'
/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/railties-5.2.2/lib/rails/command.rb:46:in `<main>'
bin/rails:4:in `require'
bin/rails:4:in `<main>'
warning: thread "Ruby-0-Thread-4: /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/internals/thread_pool.rb:6" terminated with exception (report_on_exception is true):
IOError: closed stream
select at org/jruby/RubyIO.java:3549
select at org/jruby/RubyKernel.java:665
readpartial at /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:306
read_events at /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:279
process at /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:252
run at /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:229
synchronize at org/jruby/ext/thread/Mutex.java:158
run at /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:226
_run at /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/adapter/linux.rb:39
start at /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/adapter/base.rb:78
add at /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/internals/thread_pool.rb:6
org.jruby.exceptions.IOError: (IOError) closed stream
at org.jruby.RubyIO.select(org/jruby/RubyIO.java:3549)
at org.jruby.RubyKernel.select(org/jruby/RubyKernel.java:665)
at RUBY.readpartial(/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:306)
at RUBY.read_events(/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:279)
at RUBY.process(/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:252)
at RUBY.run(/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:229)
at org.jruby.ext.thread.Mutex.synchronize(org/jruby/ext/thread/Mutex.java:158)
at RUBY.run(/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:226)
at RUBY._run(/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/adapter/linux.rb:39)
at RUBY.start(/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/adapter/base.rb:78)
at RUBY.add(/home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/lib/ruby/gems/shared/gems/listen-3.1.5/lib/listen/internals/thread_pool.rb:6)
true
$ /home/enebo/Downloads/releases/9.2.4.1/jruby-9.2.4.1/bin/jruby -S rake db:migrate
== 20181219200006 CreatePeople: migrating =====================================
-- create_table(:people)
-> 0.0082s
-> 0 rows
== 20181219200006 CreatePeople: migrated (0.0096s) ============================
Line 182 of notifier.rb doesn't invoke the callback.
Possible solutions would be to expand :all_events into a list of symbols in the watch method, use Native::Flags_to_mask to convert events.flags and the watcher's flags array on line 182, or to simply always fire the callback when flags contains :all_events.
Since Inotify not supported recursive so we adding all child directory to watch list. I tested case create new child directory, new event fire and that fine. but go to that child directory and create new file or directory --> nothing happen.
I have a depreciation warning for rb-inotify in my rails app. I was wondering if anyone else had it and how this can be resolved. It appears in almost any command, including db: commands and rails c
for console. It does not affect the performance at this point, but gives me the following error message:
$ rails c
DEPRECATION WARNING: You have Rails 2.3-style plugins in vendor/plugins! Support for these plugins
will be removed in Rails 4.0. Move them out and bundle them in your Gemfile, or fold them in to your app
as lib/myplugin/* and config/initializers/myplugin.rb. See the release notes for more on this:
http://weblog.rubyonrails.org/2012/1/4/rails-3-2-0-rc2-has-been-released.
(called from <top (required)> at /Users/jim/rails_projects/new_app/config/environment.rb:5)
Loading development environment (Rails 3.2.3)
>>
The only item I have in vendor/plugins is rb-inotify.
Please help!
Discussed here: guard/guard#833
Apparently fixed here: https://github.com/e2/rb-inotify/commits/misc_bugfixes
Specifically e2@be4cf88
Full error:
E, [2017-03-21T14:09:06.413770 #10019] ERROR -- : run() in thread failed: stream closed:\n /home/samuel/.rvm/gems/ruby-2.4.0/gems/rb-inotify-0.9.8/lib/rb-inotify/notifier.rb:304:in `readpartial'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/rb-inotify-0.9.8/lib/rb-inotify/notifier.rb:304:in `readpartial'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/rb-inotify-0.9.8/lib/rb-inotify/notifier.rb:275:in `read_events'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/rb-inotify-0.9.8/lib/rb-inotify/notifier.rb:242:in `process'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/rb-inotify-0.9.8/lib/rb-inotify/notifier.rb:225:in `run'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/listen-3.1.5/lib/listen/adapter/linux.rb:39:in `_run'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/listen-3.1.5/lib/listen/adapter/base.rb:78:in `block in start'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/listen-3.1.5/lib/listen/internals/thread_pool.rb:6:in `block in add'\n\ncalled from:\n /home/samuel/.rvm/gems/ruby-2.4.0/gems/listen-3.1.5/lib/listen/listener.rb:68:in `block in <class:Listener>'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/listen-3.1.5/lib/listen/fsm.rb:121:in `instance_eval'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/listen-3.1.5/lib/listen/fsm.rb:121:in `call'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/listen-3.1.5/lib/listen/fsm.rb:91:in `transition_with_callbacks!'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/listen-3.1.5/lib/listen/fsm.rb:57:in `transition'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/listen-3.1.5/lib/listen/listener.rb:91:in `start'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/guard-2.14.1/lib/guard/commander.rb:35:in `start'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/guard-2.14.1/lib/guard/cli/environments/valid.rb:16:in `start_guard'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/guard-2.14.1/lib/guard/cli.rb:122:in `start'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/thor-0.19.4/lib/thor/command.rb:27:in `run'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/thor-0.19.4/lib/thor/invocation.rb:126:in `invoke_command'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/thor-0.19.4/lib/thor.rb:369:in `dispatch'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/thor-0.19.4/lib/thor/base.rb:444:in `start'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/guard-2.14.1/lib/guard/aruba_adapter.rb:32:in `execute'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/guard-2.14.1/lib/guard/aruba_adapter.rb:19:in `execute!'
/home/samuel/.rvm/gems/ruby-2.4.0/gems/guard-2.14.1/bin/_guard-core:11:in `<main>'
When close
ing a notifier from within the callback-block of a watch
, then the process
call on the notifier will fail.
It seems that the event tries to access its watcher which fails because it has already been removed (from the close
call).
Script to reproduce:
require 'rb-inotify'
require 'tempfile'
file = Tempfile.new('foo')
notifier = INotify::Notifier.new
notifier.watch(file.path, :modify) do |event|
notifier.close
end
File.open(file.path, 'w') do |f|
f.write('hello')
end
notifier.process
Output:
/var/lib/gems/1.9.1/gems/rb-inotify-0.9.5/lib/rb-inotify/event.rb:129:in `callback!': undefined method `callback!' for nil:NilClass (NoMethodError)
from /var/lib/gems/1.9.1/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:238:in `block in process'
from /var/lib/gems/1.9.1/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:238:in `each'
from /var/lib/gems/1.9.1/gems/rb-inotify-0.9.5/lib/rb-inotify/notifier.rb:238:in `process'
from test.rb:15:in `<main>'
I'm not sure how this should be fixed, any hints?
I'm getting an error about RUBY_ENGINE when I try to use rb-inotify.
/usr/local/rvm/gems/ruby-2.7.4/gems/ffi-1.15.3/lib/ffi.rb: uninitialized constant RUBY_ENGINE (NameError)
We need to be able to exclude certain files when using recursive watch. Currently i did not find anything. Does it already exist? How do we use it?
Hi,
I would like to fetch the user id (UID) or username of who has deleted a file or folder entry from inotifier.
As the file is not present (after deletion), we can't get it from the stat.
Does rb-inotify
already supports it? If not how it can be addressed? Any workarounds?
Your early reply will be highly appreciated.
{
"event": "delete",
"name": "New folder",
"path": "/programs/New folder",
"type": "folder"
}
Environment details:
CentOS Linux release 7.3.1611 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
CentOS Linux release 7.3.1611 (Core)
CentOS Linux release 7.3.1611 (Core)
Thank you!
528f86a#diff-ba0ad9930c92f66b00543bcb9a88fbb6R20 added a breaking change by requiring ruby >= 2.0.0 so now installing compass (which requires rb-inotify >= 0.9) fails when it didn't an hour ago.
When used in combination with guard/listen, cycles of symlinks cause nontermination. I don't quite know whether the reason lies here or in listen
.
See also here.
Every now and then [guard] fails to start with the following message:
11:21:41 - INFO - Guard is now watching at '/home/cordawyn/Projects/test'
/home/cordawyn/.rvm/gems/ruby-1.9.3-p327-turbo/gems/rb-inotify-0.8.8/lib/rb-inotify/notifier.rb:66:in `initialize': Too many open files - Failed to initialize inotify: the user limit on the total number of inotify instances has been reached. (Errno::EMFILE)
This happens after returning the computer (notebook) from sleep mode, then launching guard (on a Rails project). To make things worse, it is not 100% reproducible (I'd say, around 80% of attempts).
I figure this might not be exactly rb-notify's bug, but rather that of either inotify or a million other kernel subsystems, but guard+rb-notify seems to be the only combo that manages to surface this issue. If you could point me to a more appropriate responsible party, it would be much appreciated ;-)
I'm trying to use rb-inotify to watch a file that gets appended to by dropbox (sync to local computer).
I have even tried watching for any events:
queue.watch(filename, :all_events) { puts "EVENT!" }
But I see nothing if dropbox modifies the file (though I do see this message if I append to the file directly).
How is the dropbox app getting around inotify in it's file modifications??
Sorry, I'm not sure whether this is expected behaviour or not. Looking at the C docs and rb-inotify docs it appears not.
On my systems (Debian Lenny & Ubuntu Lucid, Linux 2.6.26 & 2.6.32, Ruby 1.8.7, rb-inotify 0.7.2), events appear to get the one_shot flag by default.
The following script:
require 'rubygems'
require 'rb-inotify'
@notifier = INotify::Notifier.new
@notifier.watch('foo.txt', :modify) do |event|
puts event.flags.inspect
end
@notifier.process
... when I modify foo.txt, outputs ...
[:ignored]
And according to the C docs:
IN_IGNORED Watch was removed explicitly (inotify_rm_watch())
or automatically (file was deleted, or
file system was unmounted)
I'm not deleting the file, or unmounting the filesystem, so I can only assume the watch is being removed. Should I expect this?
RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.
via e.g.
spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']
Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.
There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.
I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!
Appendix:
If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies
p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.
Hello all,
According to https://nvd.nist.gov/vuln/detail/CVE-2018-1000201 ffi versions 1.9.23 and earlier have a DLL loading issue. Can https://github.com/guard/rb-inotify/blob/master/rb-inotify.gemspec be updated to require v1.9.24 or later?
Thanks!
I'd like to incorporate inotifiers into an application that has its own event loop based on Kernel.select. The #to_io method is great as far as it goes in that I can tell when new inotify events have been sent by the system, but to retrieve and parse them involves a dance with callbacks: I'd have to write a callback which saves them somewhere, call #process to call it, and then inspect the saved events when control returns from #process to my own code again.
It would be much cleaner if I could just call #get_events directly, but at present that seems to be an internal-use-only method. Would you consider making it or something very like it part of the official interface?
README.md
says of INotify::Notifier#process
:
If you don't want infinite looping,
you can also block until there are available events,
process them all at once,
and then continue on your merry way
However, inotify(7)
says:
The behavior when the buffer given to read(2) is too small to return
information about the next event depends on the kernel version: in ker‐
nels before 2.6.21, read(2) returns 0; since kernel 2.6.21, read(2)
fails with the error EINVAL.
Note that an inotify read(2)
does not necessarily need to read all events from the queue to be successful; reading at least one event is sufficient. This is not accounted for in INotify::Notifier#read_events
(called by #process
), which will simply return all events from a successful read(2)
. The implementation of #process
is therefore inconsistent with its description in README.md
.
It is also worth noting that the RDoc for #read_events
agrees with README.md
about what the behaviour should be.
I am not raising a pull request yet because I don't know if this is a documentation bug (and the implementation is correct), or an implementation bug (and the description in README.md
is the intended behaviour). Fixing the documentation is easy if that's the correct solution; if a code fix is needed, it's probably easiest to just poll #to_io
within #read_events
until there are no more events to read.
To your knowledge is there another Ruby project that compiles a C extension vs using FFI? I've done some measurements with ruby-libvips which also uses FFI and I think I have witnessed a very very small performance loss when using FFI. So was just wondering if you knew of inotify alternatives?
Thanks in advance!
I want to make a worker with inotify. I am using 32-Bit Ubuntu 12.04. Yet, I don't know why code involving rb-inotify
won't work well with current inotify.
Test: https://github.com/mufid/foreman-test (it is just a small test repo)
Init:
bundle install
The Procfile
main: bundle exec rake inotify
Test with foreman will freeze the process. No output. The inotify process also won't work.
foreman start
13:11:42 main.1 | started with pid 10134
# then the program freeze, no reaction.
But without foreman, the program actually works.
rake inotify
# --- output ---
# inotify: running...
# Watching at .
# Notifier up and running. Patchuuu!
Using Honcho does the same thing
honcho start
00:11:42 main.1 | started with pid 10555
# no reaction : /
I´ve been trying to install rbenv, ruby and rails in my Raspberry Pi 3 B+ in the past couple of days and after some issues here and there I've managed to get everything installed with no errors
With rbenv I installed both Ruby 2.6.3 and Ruby 2.5.5
Using Rails 5.2.3
and with both ruby versions I am getting the same problem when I execute the command:
rails server
brew install rbenv
rbenv install 2.6.3
gem install rails -v 5.2.3
$ cd # Change to the home directory.
$ mkdir environment # Make a environment directory.
$ cd environment/ # Change into the environment directory.
rails _5.2.3_ new hello_app
cd hello_app
rails server
pi@raspberrypi:~/environment/hello_app $ rails server
=> Booting Puma
=> Rails application starting on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
And then it should just stay there to be able to access the web app on the address indicated
First, the output shows this:
pi@raspberrypi:~/environment/hello_app $ rails server
=> Booting Puma
=> Rails 5.2.3 application starting in development
=> Run `rails server -h` for more startup options
And then the contents of the text file in the next link are shown.
Here is a link with the whole output:
https://www.dropbox.com/s/gjgo81zqeekfnvt/railsservererror.txt?dl=0
Ruby version: I´ve tried with both 2.6.3 and Ruby 2.5.5
Rails version: I've tried with 6.0.0.rc1 and with 5.2.3
Puma version: I've tried with 3.12.1 and a previous one too
User @dannyfallon helped me with a workaround and explanation as follows from the Puma github site because I thought this was an issue with the Puma web server, but I was wrong:
According to your segfault's
Control frame information
you never even reached Puma. I would think that since Puma was never reached if you swappedpuma
in your gemfile forthin
orwebrick
you still wouldn't be able to runrails server
.When you run
rails server
the application does a bunch of stuff before actually passing off theRails::Application
to a Rack server to run. In development Rails creates anEventedFileWatcher
to watch for file changes so it can reload your app without you having to stop/start your server all the time. This uses thelisten
gem, which under the hood uses some OS-specific file events so it doesn't have to keep polling. In trying to create a watch (whichlisten
does throughrb-inotify
for Linux), Ruby encountered a segmentation fault:/home/pi/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:57: [BUG] Segmentation fault at 0xe92d000e ruby 2.5.5p157 (2019-03-15 revision 67260) [armv7l-linux-eabihf] -- Control frame information ----------------------------------------------- c:0095 p:---- s:0527 e:000526 CFUNC :inotify_init c:0094 p:0041 s:0523 e:000522 METHOD /home/pi/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:57 [FINISH]
Because
rb-inotify
is using FFI and some C functions, when things go wrong it does tend to blow up badly with segmentation faults.There's lots of stuff you can do if you want to go deeper like report a bug over at FFI, attempt to recompile Ruby from source, test
inotify
on your distro outside of Ruby but you probably just want to get on with some development given you've been at it a few days.I believe to fix this you can open
config/development.rb
and replace this:# Use an evented file watcher to asynchronously detect changes in source code, # routes, locales, etc. This feature depends on the listen gem. config.file_watcher = ActiveSupport::EventedFileUpdateCheckerwith
# Use a simple file watcher to detect changes in source code config.file_watcher = ActiveSupport::FileUpdateCheckerCaveat: The
EventedFileWatcher
is supposed to use OS events to detect file changes. The
FileWatcher
will poll for changes. This may slow down reloads or cause higher system load.
Originally posted by @dannyfallon in puma/puma#1797 (comment)
The solution proposed by @dannyfallon actually allowed me to start the Web Server, but I was wondering if the people here at rb-inotify could give me a hand to try to figure out what went wrong and if there is anything I can do to fix this problem and be able to use
config.file_watcher = ActiveSupport::EventedFileUpdateChecker
Sorry for the long post...
Awaiting your comments.
P.S.: by the way, I get the same segmentation fault when I try to create a new rails app with rails version 6.0.0.rc1:
rails _6.0.0.rc1_ new hello_app
but if I use version 5.2.3 I don´t get the error
rails _5.2.3_ new hello_app
Thanks,
Hi Nathan,
We got some issue with rb-inotify and thread in a new Guard approach.
https://github.com/guard/guard/issues#issue/25
Can you confirm that rb-inotify doesn't support thread?
Thanks for your help,
Thibaud
Hi all
As far as i understand from the code, the :recursive
flag does not watch files in subdirectories, but only directories.
Is this a bug or intended?
If you have no events coming in, then calling stop
after calling run
in a separate thread will not cause run
to unblock. Instead, it will only stop after another event has been processed.
Hello Everyone. I did make some individual issues on these points but I thought I'd make one shared issue here to get everything in one place.
Shared organisation. I'd like to propose that we have a shared organisation for rb-inotify
, rb-kqueue
, and rb-fsevent
.
I'm trying to bring everyone together to form a consensus.
There are two ideas I have
guard
organisation.I'd like to propose that we consider renaming the gems. The rb-
prefix is pretty ugly, and quite non-standard by modern standards. Some ideas I have include os-
, fs-
, sys-
. Open to suggestions/discussion.
Coordinated 1.0 release. I think there is an opportunity for us to all get to 1.0 at the same time. It's not essential, but it would be nice if we could invest the time to achieve this.
Shared test suite. Since these gems are largely doing the same thing, if we exposed a uniform high-level interface, we could also have a shared high level rspec test suite. It's really easy to do, and the benefits would be great - confirming the same behaviour over multiple platforms.
Still waiting on guard/guard#922
Hi,
when I create the script asdf.rb
with the following content
require 'rb-inotify'
notifier = INotify::Notifier.new
notifier.watch('foo.txt', :delete_self) {puts "foo.txt was deleted!"}
File.delete 'foo.txt'
notifier.process
and then execute the following commands under Debian:
touch foo.txt
ruby asdf.rb
I get the output:
foo.txt was deleted!
foo.txt was deleted!
So the event fired twice. Do you know why?
When I execute the following script instead:
require 'rb-inotify'
notifier = INotify::Notifier.new
File.new 'foo.txt', 'w'
notifier.watch('foo.txt', :delete_self) {puts "foo.txt was deleted!"}
File.delete 'foo.txt'
notifier.process
then I get no output at all. So the event never fired...
I have applied watch on particular file for all the events. It notifies me all events except when file is deleted from GUI.
When file is deleted from GUI no event is fired.
When I removed file from CLI it gave me [:attrib] event.
Gaurd crashes, when rails cache files are created. It works fine if I configure Test environment cache_store to memcached instead for file store which is default.
REE 1.8.7
Rails 3.0.7
/home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/rb-inotify-0.8.5/lib/rb-inotify/watcher.rb:80:in `initialize': No such file or directory - Failed to watch "/home/shanlalit/work/x-project/tmp/cache/User.all.120110621-4065-yf1f9x-0.lock" (Errno::ENOENT) from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/rb-inotify-0.8.5/lib/rb-inotify/notifier.rb:182:in `new' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/rb-inotify-0.8.5/lib/rb-inotify/notifier.rb:182:in `watch' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/rb-inotify-0.8.5/lib/rb-inotify/notifier.rb:190:in `watch' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/rb-inotify-0.8.5/lib/rb-inotify/notifier.rb:193:in `watch' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/rb-inotify-0.8.5/lib/rb-inotify/watcher.rb:41:in `[]' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/rb-inotify-0.8.5/lib/rb-inotify/watcher.rb:41:in `callback!' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/rb-inotify-0.8.5/lib/rb-inotify/event.rb:128:in `callback!' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/rb-inotify-0.8.5/lib/rb-inotify/notifier.rb:220:in `process' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/rb-inotify-0.8.5/lib/rb-inotify/notifier.rb:220:in `each' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/rb-inotify-0.8.5/lib/rb-inotify/notifier.rb:220:in `process' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/guard-0.4.2/lib/guard/listeners/linux.rb:65:in `watch_change' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/guard-0.4.2/lib/guard/listeners/linux.rb:16:in `start' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/guard-0.4.2/lib/guard.rb:39:in `start' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/guard-0.4.2/lib/guard/cli.rb:15:in `start' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/thor-0.14.6/lib/thor/task.rb:22:in `send' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/thor-0.14.6/lib/thor/task.rb:22:in `run' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/thor-0.14.6/lib/thor/invocation.rb:118:in `invoke_task' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/thor-0.14.6/lib/thor.rb:263:in `dispatch' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/thor-0.14.6/lib/thor/base.rb:389:in `start' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/gems/guard-0.4.2/bin/guard:6 from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/bin/guard:19:in `load' from /home/shanlalit/.rvm/gems/ree-1.8.7-2011.03@rails3/bin/guard:19
It would be nice to be able to continue after a file or directory can't be opened by the watcher. May be a :ignore_errors flag?
This is what is happening to me:
irb(main):007:0> notifier.watch("/dev", :recursive, :modify, :dont_follow) do |event|
irb(main):008:1* puts event.name
irb(main):009:1> end
Errno::ENOTDIR: Not a directory - /dev/fd/3
from /usr/lib/ruby/gems/1.8/gems/rb-inotify-0.8.1/lib/rb-inotify/notifier.rb:178:in open
from /usr/lib/ruby/gems/1.8/gems/rb-inotify-0.8.1/lib/rb-inotify/notifier.rb:178:in entries
.....
If I wrap up that in a Begin Rescue block, It will add events till the first exception, but lots of files will not be watched.
I think the correct way is handling those exceptions, something like this:
begin
notifier.watch("/dev", :recursive, :modify, :dont_follow) do |event|
puts event.name
end
rescue INotify::Error::NoDirEntry => e
notifier.ignore(e.path)
retry
end
What do you think?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.