Running resque:work from capistrano.

[sreid]

I'm so far unable to run a rake task - resque:work - from capistrano,
so that it keeps running as a background process when the capistrano
ssh session terminates. I've tried various combinations of nohup,
setsid, disown etc., but nothing works. Any ideas ?

A typical command sequence might be :

cd $1
export RAILS_ENV=production
nohup bundle exec rake resque:work QUEUE=$2 >/dev/null 2>&1 &

This works ok in a putty session, but not via capistrano.

[Donovan Bray]

we use God as our runner for both unicorn and resque

on the box we use a single init script to start God.  God then is responsible for starting our app.

In the deploy scripts we interact with god, and we don't have this issue since god is already daemonized and theres no shell to send a hup to resque.

This method has been working so well in wrangling unicorn and resque, I've just got done writing in control of our redis, and I think I'll add in nginx, and remove all of those start scripts.  So God is the single init script on the box, and it can start and control the whole application environment.

If you don't like god, consider bluepill or monit.  You'll end up liking the extra monitoring and advanced notification and remediation that a management layer like that can provide.

--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en

[Russ Knaley]

Have you tried screen

[Lee Hambley]

I recommend that you don't start jobs 'blind' from capistrano, and instead use capistrano to control a server-side process monitoring daemon such as monit, resque even comes with a sample monit file.

Also if that's not desirable, http://en.wikipedia.org/wiki/Nohup - quoting from the wiki page: "nohup is a POSIX command to ignore the HUP (hangup) signal, enabling the command to keep running after the user who issues the command has logged out" (effectively once your capistrano command hangs up, and finishes)

- Lee

[sreid]

I was hoping to avoid learning another new tool such as monit for now,
but maybe it's the only way. I already tried nohup - see original
post.

Does anyone know why in particular resque:work is failing to stay
running (or how to debug it) ? I can start redis-server and resque-web
processes fine from capistrano.

On May 12, 7:24 am, Lee Hambley <lee.hamb...@gmail.com> wrote:
> I recommend that you don't start jobs 'blind' from capistrano, and instead
> use capistrano to control a server-side process monitoring daemon such as
> monit, resque even comes with a sample monit file.
>

> Also if that's not desirable,http://en.wikipedia.org/wiki/Nohup- quoting
> from the wiki page: "*nohup* is a POSIX
> <http://en.wikipedia.org/wiki/POSIX> command
> to ignore the HUP <http://en.wikipedia.org/wiki/SIGHUP> (hangup) signal,

[Lee Hambley]

>  I can start redis-server and resque-web processes fine from capistrano.

They may be smart enough to daemonize themselves by default. Processes (in about 3 lines of code) can detach themselves from the terminal, and go into the background, detached from Terminals, users, etc - simply `daemons`. If they do that, then that's a smart move from their vendor… that's often what you see with a --daemonize flag, or something.

( I hope that at least clears things up, even if that's not the answer you were looking for! )

- Lee

[sreid]

I though using & at the end of the line :

nohup bundle exec rake resque:work QUEUE=$2 >/dev/null 2>&1 &

would make it a background task, and nohup prevents it being shutdown
when the ssh session ends. This seems to be a fairly common technique.

Anyway, I've found a hack which works for me, although I'm not sure
why. I added sleep 10 after the nohup call above.

Perhaps the resque process outputs something at startup and then fails
as the ssh session has been closed. If this is the case, I thought >/
dev/null 2>& should have fixed that.

[Lee Hambley]

Using monit is the best way! (but I can understand you don't want to learn another tool) Monit is so ubiquitous that it's a valuable skill.

Also, take a look at resque-pool, you might not need "pools" of workers now… but it has a slightly nicer interface for starting workers, and it might solve some problems for you.

- Lee

[Donovan Bray]

You might try

bundle exec nohup rake ...

But monit is easy really and you'll be better off for it in the long run.