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.
Sorry for my ignorance, but why do you need 20 watches for the same processes (20.times do...)??. I really don`t get it.
@sandrods That is for 20 separate worker instances
Great post I like it thanks for sharing
free online games
regards,
Some useful piece of info thanks!
logo design