Announcing daemon_generator

After writing rails_cron, and working with backgroundrb, I realized that I want something simpler. Much simpler. So I wrote the daemon_generator plugin. I think the whole thing is about 50 lines of code.

"./script/generate daemon <name>" gives you a simple stub that you can dump code in that will run in the rails environment as a background process. You're responsible for making it do something useful (try accessing stored tasks in a memcache or DB-based queue). If you want messaging, try backgroundrb.

Features:

• Capistrano-friendly i.e.:
  

  task :after_restart do
    run "#{current_path}/script/daemons restart"
  end



• Per-daemon start scripts


• Per-app start scripts


• Graceful stop and restart


• Per-daemon logging in your log folder


• Automatic restart of a crashed daemon


• Not thread-based

Go get the plugin:
daemon_generator 0.5.0 | README

Comments

[Tom]

A bug I've found with rails_cron is that using threads and running two Rails tasks simultaneously just doesn't work - one of the two jobs just exits quietly.

I know that things like Mongrel and WEBrick look at the ActiveRecord concurrency setting and wrap their own protection around Rails calls, but rails_cron doesn't.

For my use, I changed the code to run my jobs on the main thread, which makes them sequential, but I no longer get strange results.

[Kyle]

Tom: That's one of the reasons that I wanted to go simpler.

Daemon_generator lets you run Rails processes in the background, without concern for threads, databases, and messaging. Bring your own, debug your own.

[Jordan Arentsen]

I really like the sound of this library. I tried installing it, but I tried to run the generator, it said that there wasn't any generators of that name. Do you have any idea of what could be going on?

[Douglas F Shearer]

Hi Kyle.

Great piece of code, I've made good use of this week.
I've written a small how-to guide on setup, as it took me a while to get it worked out (thanks to other comments here).

It's available at: http://douglasfshearer.dyndns.org/blog/cron-jobs-in-ruby-on-rails Let me know what you think, I'm open to additions and corrections.

Cheers.

[Brent]

Is there an explanation of the options in daemons.yml anywhere?

[Tom Fowler]

great plugin - working very well for me. Thanks!

One very,very small issue I ran into...

the ctl files generated in lib/daemons/

do a require on active_support - I think to
get access to Hash with_indiffent_access on the
options initialized from config/daemons.yml...

The problem is that the require for active_support
by passes your vendor directory.

Most people will have rails installed in their
ruby installation so they won't notice it...

In my case, I don't have root access - so I can't
install rails to my system ruby. I have installed in my vendor directory..

So I just got rid of the active_support require
and did a hack on the options hash to create
symbol based keys from the string based keys that get loaded out of the daemons.yml file...

Anyway, thanks for the plugin..
cheers,tom

[non]

How does this compare to dctl? http://dctl.rubyforge.org/

[Travis Hume]

Anyone having issues with stop/start/restart on capistrano deployment? I've added a after_deply hook to call "./script/daemons restart" but this will not start the daemons on an initial deployment. So I changed it to do a stop and a start, but the daemons are not being stopped and are instead just piling up. 2 deployments (or cap restarts) and I have 2 daemons running. Hope I'm missing something.

[Micah]

I can't get my daemons to stop. I call the stop command, but it looks as though they are automatically restarted somehow.

[Toby Hede]

The SVN account doesn't appear to be working ... anyone know where to get this code?

[Ron]

Kyle, I'm a bit new to Rails, not to mention daemon_generator -- I have a library, lib/etsmon/etsmon.rb that I want to make use of from inside my daemon (the .rb file), but I can't seem to get a require to this library to work.

Any tips?
Thanks,
Ron

[Mario]

I've also been having some troubles. I keep getting the following series of errors message. I've been googling around, but can't seem to find much documentation, other than the a cached thread on a similar error occurring on a previous version.

failed to allocate memory
stack level too deep
no such file to load -- daemons

Is there something that I'm doing wrong?

Thanks!

-Mario

[Scott]

Kyle, I noticed after I start my daemon, there are two ruby processes running. One has no CPU load and no run time. The other looks like its the one actually doing the processing, is this normal or did i mess something up here?

-scott

[Jon]

Ron,

I got rid of the stack error by replacing

ActiveRecord::Base.logger << "somestr"

with

logger = ActiveRecord::Base.logger
logger.info("somestr")

[Fred]

I also have troubles with stopping daemons using capistrano...
Daemons are sometimes stopped. And sometimes just continue running..

I think this could happen when they are busy. The daemon stop process would wait for its work to be finished before actually stopping the process. And I suppose it gets timed out when this is too long.
This could be the reason for the randomness of the stop..

Would be great if you could give us any update around that. No much support and documentation can be found for this.

Anyway, except from that,
great plugin :)

Thanks

[Fred]

Hi again guys,

I am just gonna reply to myself here... and all the guys having the same problem as I had.

I just realized the daemons would not stop using capistrano if they where restarted before they would actually get stopped.

I'll explain.

I noticed, as explained in former mail, that the daemons would wait for the current work (in while $running loop) to be finished before they stop.
When using capistrano, the execution of the deployment code has good chance to be faster than that.
Now the problem is when you store your daemons Pid files in a shared folder, with the same name for different version of daemons.
Starting a new daemon would overwrite the old Pid file. If that happens before the daemon actually got stopped. This daemon will never actually get stopped.

To fix this problem, just us a none shared folder for your daemon pids. Somewhere in the current version of your ruby project is just fine...

Personally, I am using the root of my ruby project. As my daemons are located in lib/daemons/, I have set this parameters in daemons.yml:
dir_mode: script
dir: ../..

Now, to answer people asking what options are allowed in this daemons.yml file, you can find all your answers if you take a quick look inside daemons.rb file, into the daemon gem. Everything is here, in comment.

Here is the exemple provided (not in yml format):
# === Example:
# options = {
# :app_name => "my_app",
# :ARGV => ['start', '-f']
# :dir_mode => :script,
# :dir => 'pids',
# :multiple => true,
# :ontop => true,
# :mode => :exec,
# :backtrace => true,
# :monitor => true,
# :script => "path/to/script.rb"
# }

Once again...

Great work on this gem !

[Fred]

One last thing...
Sorry for monologue..

You would have to disable monitoring using:
monitor: false
from your daemons.yml file.

Because the monitor was actually restarting former daemons... when they would finally get stopped -_-'

I am not proud of that, to be honest, but this is the only solution I found right now.

Fred

[Mike Stenhouse]

Hiya Kyle!

Looks like your repo is down, and has been for a few days. Have you retired it or will it become accessible again? After a thousand issues with BackgroundRB I'm trying to move to something more lightweight... like Daemons!

Cheers

Mike

[Arman]

hi kyle

I'm trying to set up daemon generator in my project. I've followed instruction from the following link
http://douglasfshearer.com/blog/cron-jobs-in-ruby-on-rails
But after starting daemon i've noticed that production.log is blank :( I followed the test.rb.log file where it says

*** below you find the most recent exception thrown, this will be likely (but not certainly) the exception that made the application exit abnormally ***
#= 0.0.0)
>
*** below you find all exception objects found in memory, some of them may have been thrown in your application, others may just be in memory because they are standard exceptions ***
#
#
#
#
#= 0.0.0)
>

Mysql is working fine with my other applications. I've recent version of daemon 1.0.10 and ruby gem.
What else i should do? Please help....