OSX hangs on close_io

[sblackstone]

I'm using delayed_job which utilizes daemons. When I run "delayed_job run" from my application, its hanging in this block on my OSX box (but seems ok in my docker container on Ubuntu)..

  def close_io
    # Make sure all input/output streams are closed
    # Part I: close all IO objects (except for $stdin/$stdout/$stderr)
    ObjectSpace.each_object(IO) do |io|
      unless [$stdin, $stdout, $stderr].include?(io)
        io.close rescue nil
      end
    end

If I add a print in the loop here, I get this:

jack:import_tester sblackstone$ ./bin/delayed_job run
#<File:/Users/sblackstone/.rvm/gems/ruby-2.3.1/gems/actioncable-5.0.0.1/lib/action_cable/channel.rb (closed)>
#<File:/Users/sblackstone/code/import_tester/config/secrets.yml (closed)>
#<File:/Users/sblackstone/code/import_tester/log/development.log>
#<IO:fd 32>

which from the output of lsof is some sort of pipe.

If I change the order of the functions in close_io so that it runs the close_fd loop before the "io.close" loop, it manages to get going (albeit other things seem to break like logging)

If this isn't a daemons issue, I'm happy to open something with the delayed_job folks - Thanks..

I'm using OSX El Cap..

[thuehlinger]

Can you try to replace [$stdin, $stdout, $stderr]by [STDIN, STDOUT, STDERR]? There was a change in the last release that might have had undesired side effects.

[sblackstone]

I tried changing it to this:

    ObjectSpace.each_object(IO) do |io|
      unless [STDIN, STDOUT, STDERR].include?(io)
        print "Attempting "
        pp io
        io.close rescue nil
      else 
        puts "Skipping #{io}"
      end
    end

And the output is:

jack:import_tester sblackstone$ ./bin/delayed_job run
Skipping #<IO:0x007fae328a2b08>
Skipping #<IO:0x007fae328a2ba8>
Skipping #<IO:0x007fae328a2c48>
Attempting #<File:/Users/sblackstone/code/import_tester/log/development.log>
Attempting #<File:/Users/sblackstone/.rvm/gems/ruby-2.3.1/gems/delayed_job-4.1.2/lib/delayed/command.rb (closed)>
Attempting #<IO:fd 20>

with lsof showing:

ruby      28355 sblackstone   20     PIPE 0x2e2061ee1d21f023       16384         ->0x2e2061ee3d31bc23

[thuehlinger]

So is it still hanging? (in the original order of the calls)

[sblackstone]

Yep - its hanging at the last line in that output... Calling close on that fd..

[thuehlinger]

Then I rather don't think it is a daemons issue. Can you open a bug report for delayed_job?

[sblackstone]

will do - thanks.

[sblackstone]

Cross posting this from the delayed_job ticket:

Alright, so it only occurs when rails is running in development mode. If you run bin/delayed_job run with daemons, it will hang..

But then if you killall -9 fsevent_watch (part of Rails dev mode) - it will then get past the hung IO.close and enter in into the normal run loop and start processing jobs..

[sblackstone]

Update - So delayed_job calls Daemons.run_proc from within an environment that already has Rails loaded and Rails doesn't seem to like having all its IO closed out from underneath it.

Perhaps a cmd line option is in order to disable the close_io call within simulate? Or running without simulate at all?