delayed_job icon indicating copy to clipboard operation
delayed_job copied to clipboard

Error: run() in thread failed: closed stream - 4.1.8

Open treenewbee opened this issue 5 years ago • 11 comments

Only happens when RAILS_ENV is development: bin/delayed_job run

ERROR -- : run() in thread failed: closed stream:\n .rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/rb-inotify-0.10.0/lib/rb-inotify/notifier.rb:44:in `fileno'

treenewbee avatar Aug 12 '19 17:08 treenewbee

I am not sure what you are trying to do with rb-inotify in DJ, but DJ does not use that gem and DJ is not a threaded worker.

albus522 avatar Aug 12 '19 17:08 albus522

I didn't code anything with rb-inotify, when you create a fresh rails6 application with delayed_job 4.1.8.beta1, and bin/delayed_job run, this is what you will get.

Issue is caused by this line in config/environments/development.rb config.file_watcher = ActiveSupport::EventedFileUpdateChecker

treenewbee avatar Aug 12 '19 17:08 treenewbee

I would suggest using the rake task instead with rake jobs:work. The bin script is oriented towards daemonizing a process and I think that is interfering with the file watcher.

albus522 avatar Aug 12 '19 17:08 albus522

bin/delayed_job start seems to be working totally fine, which daemonize to a process.

treenewbee avatar Aug 12 '19 17:08 treenewbee

If you touch log/delayed_job.log, the error is gone, rm log/delayed_job.log the error is back

Bug is likely here: 2478a92cc6cda0709d73ffa612d195b4ea19e191

Which changed something about log/path.

treenewbee avatar Aug 12 '19 18:08 treenewbee

The issue is most likely https://github.com/collectiveidea/delayed_job/blob/master/lib/delayed/worker.rb#L83-L92 and is required so workers don't share open file handles and also plays into daemonizing

albus522 avatar Aug 12 '19 20:08 albus522

4.1.8 same error occurs even with long/delayed_job.log presents

treenewbee avatar Nov 01 '19 13:11 treenewbee

You are probably better off using the rake task in development

albus522 avatar Nov 01 '19 14:11 albus522

Using rake jobs:work in development seems ok.

But has anyone a recommendation how to use Delayed Job with threaded workers in production? All best practices (e.g. 12Factor-Apps) recommend using a single process as application entrypoint, and it seems odd for users to rely on a 3rd party monitoring daemon. You could of course just scale the containers horizontally, but that's quite a waste of resources memory-wise.

I'd be happy if someone could suggest a solution for this…

Shark avatar Dec 04 '19 08:12 Shark

DJ is a process based worker scheme. Other background processing libraries specialize in threaded worker management.

albus522 avatar Dec 04 '19 15:12 albus522

I'm very confused by all this. I've been working with delayed_job_recurring, which would serve the purpose for me of moving all the moving parts of my app into the 'rubysphere' of my application (as opposed to, Whenever, which uses/relies on cron (great gem by the way). for me, delayed_job has been all kinds of weird inexplicable issues (for someone of my meager abilities) but key is, I need to run demonize in production. I think. Don't I? So how is the recommendation to run "rake" helpful? How can I get delay_job daemon to run? First in development, as I try very hard to keep my environments as similar as I can. Thanks.

jmcbri avatar May 17 '21 23:05 jmcbri

Closing stale

albus522 avatar Jul 26 '24 19:07 albus522