Running the start/restart script doesn't end the capistrano task about capistrano-resque HOT 3 CLOSED

The long and the short of it is that Resque does not disconnect from STDOUT and STDERR when BACKGROUND=yes rake resque:work is called, so it isn't by definition a well-behaved daemon; this cannot be changed/fixed on the Resque side without a major version bump, and that's not something I'm willing to take on without significant discussion with the other contributors & maintainers, especially considering the following.

The maintainer of Cap3 & SSHKit @leehambley rightfully has reservations about explicitly supporting badly-behaved processes, and raises valid points about using this approach in the first place:

I spent the last few years trying to find a knowledge war about badly behaved programs,
and I'm not keen to do the same again. I also rarely see the use-case for starting daemons
via Cap. (Surely, you'd want them monitored, and started by the system, and you would
instruct the system to start them, using monit, god, bluepill, initd, runit, daemontools, initd, etc?)

An immediate solution is would be to avoid Resque's BACKGROUND=yes, and instead to invoke the rake task using Cap3's background; you will lose the startup noise, which would cause launch-failure issues to be harder to debug.

Ultimately, the right solution is to follow the advice above and use a system-level utility to ensure that the task is running; failing to do so is an operations nightmare waiting to happen.

from capistrano-resque.

Ultimately, the right solution is to follow the advice above and use a system-level utility to ensure that the task is running; failing to do so is an operations nightmare waiting to happen.

Absolutely, and on all modern Linuxes this is well documented, and easy. My personal preference being upstart on systems where it is supported natively, and runit (C) or supervisord (Python) on systems where there is only systemv initd

from capistrano-resque.

#82 fixes this by redirecting stderr/stdout to /dev/null (or to whatever you configure in the :resque_log_file setting).

However, as discussed above, Capistrano isn't a great way to directly handle daemonized processes (I wound up personally switching to upstart for resque and no longer use capistrano-resque in to deploy in production).

I'll probably add some info to the README recommending something like upstart/systemd/initd/etc. instead of using this gem.

from capistrano-resque.