This rake task runs in the root directory, so I had to specify the path to rails root in the rake libdir option to get this to work
w.start = "rake -f #{rails_root}/Rakefile -I #{rails_root} RAILS_ENV=production jobs:work"
prefixing the start command with "cd #{rails_root} && rake..." will not work because this command appears to create two processes causing god to monitor the first process (which is caused by the cd command?) and not the rake command. Using this approach will continually add a new rake process every time god is restarted (you'll want to "sudo god restart dj" on every deploy).
This may be obvious, but a good way to debug this is to just run this rake task (as your app user) directly on the server to make sure the rake task isn't failing.
18 Nov 2008
Quick Q regarding this… does delayed_job ever go out of the ‘init’ phase (god status etc wise)?
Apparently the rake task ain’t daemonized or anything and here it never reaches the ‘up’ state…
This rake task runs in the root directory, so I had to specify the path to rails root in the rake libdir option to get this to work
w.start = "rake -f #{rails_root}/Rakefile -I #{rails_root} RAILS_ENV=production jobs:work"
prefixing the start command with "cd #{rails_root} && rake..." will not work because this command appears to create two processes causing god to monitor the first process (which is caused by the cd command?) and not the rake command. Using this approach will continually add a new rake process every time god is restarted (you'll want to "sudo god restart dj" on every deploy).
This may be obvious, but a good way to debug this is to just run this rake task (as your app user) directly on the server to make sure the rake task isn't failing.