How to stop Good Job?

[ianbradbury-bizzibody]

Is there a way to stop Good Job?

An opposite to bundle exec good_job start

[bensheldon]

I assume you're running as a background daemon; otherwise ctrl-c will kill the foregrounded process.

There isn't currently a command to stop the GoodJob background daemon process. You can check the pidfile (default is in your rails app's tmp/pidfiles/good_job.pid) and then kill that process (kill [PID]).

Can you tell me a bit more about how you're running GoodJob?

[ianbradbury-bizzibody]

The app is deployed using Cloud66 (DevOps is not my thing) and I was struggling to understand where GoodJob was running. At one time I thought it was running on both the web servers, which lead to my question regarding stopping GJ. I need to get better at deployment. Anyhow. Thank you.

[bensheldon]

By default, GoodJob in production environment runs with "external" execution mode. Meaning you have to run a separate worker process (good_job start).

It looks like Cloud66 is a containerized environment with a concept of a background worker, which is where GoodJob would run: https://help.cloud66.com/rails/the-basics/stack-definition.html#background-workers-optional

[dehjli85]

When running GoodJob as a background daemon, I noticed it creates an entry in the good_job_processes table. If you execute a kill command, it stops the process, but the entry in that table is still exists.

My assumption is that the table is supposed to be keep track of active processes running. Is there an elegant way to removing that entry in the table when stopping the background process?

EDIT: One thing I just now noticed is that even if the row in the table isn't deleted when the process is stopped, when good_job is restarted, it replaces that row with a new one. The original reason I was asking this is because every time we do a deployment, I assumed we'd need to:

1. Stop the existing process on our worker
2. Delete the database row in the table (since killing the process doesn't do that automatically)
3. Start a new process on the worker

I thought without doing (2), the database table would continually add rows every time we started a new process, but that doesn't appear to be the case. So now I'm trying to figure out if the table may not be accurate (since it may have data about processes that have been terminated) what is the good_job_processes table for?

[bensheldon]

If you're sending a KILL, GoodJob won't clean up the processes table until you start another worker (that behavior lives here). If you send TERM/INT, GoodJob will clean up its process entry on exit. GoodJob also won't gracefully exit on KILL either; you should avoid sending KILL if you can.

A functional change in GoodJob would be to have a process heartbeat and a TTL to somewhat filter the entries in the table in a situation where a process is killed.

[dehjli85]

super helpful, thanks!