Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We��ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not working on rails 4 server running on daemon mode (-d) #165

Closed
messutied opened this issue Sep 10, 2015 · 15 comments
Closed

Not working on rails 4 server running on daemon mode (-d) #165

messutied opened this issue Sep 10, 2015 · 15 comments

Comments

@messutied
Copy link

Tested with the simple example from the readme:

# config/initializers/scheduler.rb

require 'rufus-scheduler'

s = Rufus::Scheduler.singleton

s.every '1m' do
  Rails.logger.info "hello, it's #{Time.now}"
end

When starting the rails server with rails server -d &, rufus scheduled tasks won't fire up.

I've found out that adding s.join at the end of the script fixes the issue when running as daemon, but when running just as rails server the web server won't work, so I guess this is not intended to be used with rails.

@jmettraux
Copy link
Owner

Could you please tell which web server you're running Rails on?
Then, could you please give here the first 100 lines of the Rails log you obtain?
Could you please state what operating system you're running on and what version of Ruby?
Anything else you forgot to mention?

Thanks in advance.

@jmettraux
Copy link
Owner

I've found out that adding s.join at the end of the script fixes the issue when running as daemon, but when running just as rails server the web server won't work, so I guess this is not intended to be used with rails.

Indeed s.join is intended only for stand-alone scripts.

@messutied
Copy link
Author

Server: thin
OS: We have reproduced this on MacOS and Linux Ubuntu
Ruby version: 1.9.3p551

The first lines of the server booting not in daemon mode:

=> Booting Thin
=> Rails 4.2.0 application starting in development on http://localhost:3003
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
Thin web server (v1.6.3 codename Protein Powder)
Maximum connections set to 1024
Listening on localhost:3003, CTRL+C to stop
2015-09-10 18:03:00.234 [INFO ] This is a rufus scheduled task (pid:45119)
2015-09-10 18:03:31.731 [INFO ] This is a rufus scheduled task (pid:45119)

The first lines of the log in daemon mode:

2015-09-10 18:06:06.775 [INFO ] Setting up scheduled jobs... (pid:45152)
@jmettraux
Copy link
Owner

Have you tried flushing the logger?
Have you tried with Webrick (not Thin)?

@jmettraux
Copy link
Owner

Interesting, "Setting up scheduled jobs..." appears in daemon mode, but not in "normal" mode.

@jmettraux
Copy link
Owner

OK, I guess the thread for the scheduler is created before the -d daemon double fork. Looking up...

@messutied
Copy link
Author

Just tried with Webrick, seeing the same behavior.

@jmettraux
Copy link
Owner

I tested on Rails 3.2.22 / OSX and seeing the same behaviour. Now, what I don't understand is why nobody did complain in all those years. One possible explanation would be that only a few people use -d.

@messutied
Copy link
Author

It surprised me too not to find an issue here about it already, I guess -d is not as commonly used as I thought.

@messutied
Copy link
Author

I did found one or two posts on stackoverflow about it though.

@jmettraux
Copy link
Owner

Could you please provide the links to those posts?

@jmettraux
Copy link
Owner

I like runit http://www.mikeperham.com/2014/07/07/use-runit/ to run stuff. I never daemonize development servers.

@jmettraux
Copy link
Owner

Another solution would be to use Unicorn and start the scheduler in an after_fork block.

https://devcenter.heroku.com/articles/rails-unicorn

@jmettraux
Copy link
Owner

Just tried on OSX with Unicorn 4.9.0 and bundle exec unicorn -D, without bothering about writing an after_fork and it works out of the box. The main process forks a worker process and that worker process hosts the scheduler thread.

I will write a piece of documentation to close this issue.

@messutied
Copy link
Author

OK thanks for the support @jmettraux :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants