guard / rb-inotify Goto Github PK

A thorough inotify wrapper for Ruby using FFI.

License: MIT License

Ruby 100.00%

rb-inotify's Introduction

Guard

Guard automates various tasks by running custom rules whenever file or directories are modified.

It's frequently used by software developers, web designers, writers and other specialists to avoid mundane, repetitive actions and commands such as "relaunching" tools after changing source files or configurations.

Common use cases include: an IDE replacement, web development tools, designing "smart" and "responsive" build systems/workflows, automating various project tasks and installing/monitoring various system services.

For a full categorized list of known Guard plugins, look here: https://github.com/guard/guard/wiki/Guard-Plugins

If you have any questions about Guard or want to share some information with the Guard community, please go to one of the following places:

Guard Wiki
Google group.
StackOverflow.
IRC channel #guard (irc.freenode.net) for chatting.

Before you file an issue, make sure you have read the known issues and file an issue sections that contains some important information.

Features

File system changes handled by our awesome Listen gem.
Support for visual system notifications.
Huge eco-system with more than 300 Guard plugins.
Tested against the latest Ruby 2.4.x, 2.5.x, 2.6.x, JRuby & Rubinius. See .travis-ci.yml for the exact versions.

Screencast

Two nice screencasts are available to help you get started:

Guard on RailsCast.
Guard is Your Best Friend on Net Tuts+.

Installation

The simplest way to install Guard is to use Bundler.

Add Guard (and any other dependencies) to a Gemfile in your project’s root:

group :development do
  gem 'guard'
end

then install it by running Bundler:

$ bundle

Generate an empty Guardfile with:

$ bundle exec guard init

Run Guard through Bundler with:

$ bundle exec guard

If you are on Mac OS X and have problems with either Guard not reacting to file changes or Pry behaving strange, then you should add proper Readline support to Ruby on macOS.

Avoiding gem/dependency problems

It's important that you always run Guard through Bundler to avoid errors.

If you're getting sick of typing bundle exec all the time, try one of the following:

(Recommended) Running bundle binstub guard will create bin/guard in your project, which means running bin/guard (tab completion will save you a key stroke or two) will have the exact same result as bundle exec guard.
Or, you can alias be="bundle exec" in your .bashrc or similar and the execute only be guard. Protip: It will work for all comands executed in bundle exec context!
Or, for RubyGems >= 2.2.0 (at least, though the more recent the better), simply set the RUBYGEMS_GEMDEPS environment variable to - (for autodetecting the Gemfile in the current or parent directories) or set it to the path of your Gemfile.

(To upgrade RubyGems from RVM, use the rvm rubygems command).

NOTE: this Rubygems feature is still under development still lacks many features of bundler

Or, for RubyGems < 2.2.0 check out the Rubygems Bundler.

Add Guard plugins

Guard is now ready to use and you should add some Guard plugins for your specific use. Start exploring the many Guard plugins available by browsing the Guard organization on GitHub or by searching for guard- on RubyGems.

When you have found a Guard plugin of your interest, add it to your Gemfile:

group :development do
  gem '<guard-plugin-name>'
end

See the init section of the Guard usage below to see how to install the supplied plugin template that you can install and to suit your needs.

Usage

Guard is run from the command line. Please open your terminal and go to your project work directory.

Look here for a full list of Guard commands

Start

Just launch Guard inside your Ruby or Rails project with:

$ bundle exec guard

Guard will look for a Guardfile or guardfile.rb in your current directory. If it does not find one, it will look in your $HOME directory for a .Guardfile.

Please look here to see all the command line options for Guard

Interactions

Please read how to interact with Guard on the console and which signals Guard accepts

Guardfile DSL

For details on extending your Guardfile look at Guardfile examples or look at a list of commands Guardfile-DSL / Configuring-Guard

Issues

Before reporting a problem, please read how to File an issue.

Development / Contributing

See the Contributing Guide.

Releasing

Prerequisites

You must have commit rights to the GitHub repository.
You must have push rights for rubygems.org.

How to release

Determine which would be the correct next version number according to semver.
Update the version in ./lib/guard/version.rb.
Commit the version in a single commit, the message should be "Bump VERSION to X.Y.Z".
Push and open a pull request.
Once CI is green, merge the pull request.
Pull the changes locally and run bundle exec rake release:full; this will tag, push to GitHub, publish to rubygems.org, and publish the release notes .

rb-inotify's People

Contributors

Stargazers

Watchers

rb-inotify's Issues

unhandled EINTR

steps to reproduce:

create a notifier (like https://gist.github.com/671294)
run it
background it
foreground it

expected behavior:

notifier will continue notifying

actual behavior:

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

License missing from gemspec

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.

rdoc

Hi!

Where can I find a rdoc? rdoc.info didn't quite work...

Callbacks don't fire when using :recursive and :all_events

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.

Possible "watcher" leak

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 #closed, 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 #closed , 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).

Compiled C Extension Non-FFI Tools?

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!

Watchers are one_shot by default ... by design or not?

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?

ERROR -- : run() in thread failed: stream closed:\n rb-inotify-0.9.8/lib/rb-inotify/notifier.rb:304:in `readpartial'

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>'

Get UID/Username of a deleted file or folder entry

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:

{
  "event": "delete",
  "name": "New folder",
  "path": "/programs/New folder",
  "type": "folder"
}

Environment details:

OS:

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)

Ruby and gem version:
- ruby-2.4.4 [ x86_64 ]
- rb-inotify (0.9.10)

Thank you!

Strange results when watching a single file

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?

Update ruby-ffi version

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!

Compass watch crashes on rb-inotify.

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?

Breaking change in 0.9.9 from 0.9.8

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.

Ability to exclude certain files when using recursive watch

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?

Version 0.9.7 can't be downloaded from rubygems.org

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

Upgrading old application from Ruby 1.8.7 to 2.7.4, getting error about RUBY_ENGINE in ffi

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)

Wishlist: non-callback interface

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?

stack level too deep when running with musl on Alpine

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

Description

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.

Steps

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.

Output

$ 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

Expected

No crash, page should be served as normal.

Propotal: Unit test?

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.

Different events generated while monitoring file and directory (with file)

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!

Better coordination/shared organisation

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
- Using the guard organisation.
- Creating a new 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.

cc @mat813 @rymai @thibaudgg

Allows versions of ffi (1.9.22, 1.9.23) that throw SIGABRT (RHEL/Centos) or Segfault (MacOS)

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.

Event not fired on Deletion of file from GUI

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.

Requires reregistering of watchers

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)
}

Closing notifier in watch-callback leads to error

When closeing 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?

Cycles of symlinks cause infinite loop/recursion

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.

Strange behavior of :delete_self

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...

inotify somehow missing modification events for dropbox file

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??

Recursive flag does not watch files in subdirectories

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?

Watcher stopping after error

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?

Activating watchers

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?

HELP: How can I find the old name of a file/directory when it is renamed?

stop will not stop immediately. it will stop after the next event

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.

Too many open files - Failed to initialize inotify: the user limit on the total number of inotify instances has been reached.

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 ;-)

rb-inotify does not yet work on JRuby

use native read calls to work around JVM's current lack of real file descriptors

Build failure on JRuby

@matthewd any ideas?

https://travis-ci.org/guard/rb-inotify/jobs/303495775

Multiple event when file created

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.

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) ============================

INotify::Notifier#process does not necessarily process all events

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.

On Rails cache files, No such file or directory - Failed to watch

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

New child directory not being watched

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.

warning: rb_safe_level will be removed in Ruby 3.0

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

Permissions broken

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.

Depreciation warning

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!

rb-inotify does not work well with Foreman

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 : /

Threadable?

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

Add License information to Gemspec

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.

Starting Rails Server fails on Raspberry PI 3 B+

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

Steps to reproduce

On a Raspberry Pi install rbenv using brew

brew install rbenv

Then use the following command to install ruby

rbenv install 2.6.3

Then install rails:

gem install rails -v 5.2.3

Create a new folder to hold your application and go to that folder:

$ cd                  # Change to the home directory.
$ mkdir environment     # Make a environment directory.
$ cd environment/       # Change into the environment directory.

Use rails to create the application inside the previous folder:

rails _5.2.3_ new hello_app

Go to the recently created 'hello_app' folder

cd hello_app

Start the rails server

rails server

Expected behavior

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

Actual behavior

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

System configuration

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

Workaround

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 swapped puma in your gemfile for thin or webrick you still wouldn't be able to run rails server.

When you run rails server the application does a bunch of stuff before actually passing off the Rails::Application to a Rack server to run. In development Rails creates an EventedFileWatcher to watch for file changes so it can reload your app without you having to stop/start your server all the time. This uses the listen 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 (which listen does through rb-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::EventedFileUpdateChecker
with
  # Use a simple file watcher to detect changes in source code
  config.file_watcher = ActiveSupport::FileUpdateChecker
Caveat: 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,

Test on 2.6

Still waiting on guard/guard#922

Ruby 1.9.2: notifier.rb throws exception if non UTF-8 characters are in filenames

/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'

guard / rb-inotify Goto Github PK

rb-inotify's Introduction

Guard

Features

Screencast

Installation

Avoiding gem/dependency problems

Add Guard plugins

Usage

Start

Interactions

Guardfile DSL

Issues

Development / Contributing

Releasing

Prerequisites

How to release

Author

Core Team

Contributors

rb-inotify's People

Contributors

Stargazers

Watchers

Forkers

rb-inotify's Issues

steps to reproduce:

expected behavior:

actual behavior:

Description

Steps

Output

Expected

Steps to reproduce

Expected behavior

Actual behavior

System configuration

Workaround

Recommend Projects

Recommend Topics

Recommend Org