Uploads or exports stuck on the on-screen log with no progress? Background jobs not completing? This guide walks through how to check and recover the worker layers involved. Docker deployments run three layers, each as its own container managed with docker compose: app (puma), resque (the background job workers), and the container runtime standing in for god (the process monitor). VM deployments run the same three layers as OS processes, all supervised by god.
After triggering an upload or export, the on-screen log should update continuously until Worker process completed appears. If it stalls with no progress, work through the sections below in order.
On a Docker deployment, Docker Compose supervises each service as its own container. On a VM deployment, god is the process monitoring service that supervises all the other workers — if god itself isn't running, nothing else will be either, so this is always the first thing to check there.
Run the following from your Dradis installation directory (where compose.yaml lives):
docker compose psEvery service should show a state of Up (or running). If a service is missing, restarting, or shows Exit, jump to the Resque or Puma sections below for the specific service to restart, or restart the whole stack with:
docker compose restartdocker compose logs [service-name] shows a container's entrypoint/stdout output, not the application's own log files — see the Resque log files and Puma log files sections below for how to reach those.
Run the following in the console as dradispro:
god statusThe expected output is:
cic-puma: up
dradispro-puma: up
nginx: up
resque:
cic-resque-1: up
dradispro-resque-1: upIf any process shows as down, or if the god command itself fails, try restarting god:
sudo /etc/init.d/god restartgod statusIf you've recently rebooted the instance and god didn't come back up cleanly, force it to reload its configuration:
god load /etc/god.d/dradispro-puma.godgod load /etc/god.d/cic-puma.godgod restartStill not right? Check the god log for more detail:
vi /var/log/god.logIf the god command returns command not found, your terminal session may not have loaded the correct environment. See the SSH Environment section of the instance troubleshooting guide.
Resque workers handle background jobs — uploads, exports, migrations, and project tasks. A stuck resque process will cause uploads and exports to stall on the progress log even though the rest of the stack reports as up.
Resque runs in its own container, so a targeted restart is a single command:
docker compose restart resqueRetry the upload or export in the web app. If it's still stalling, move on to clearing the jobs queue.
The first thing to try is a targeted resque restart via god:
god restart dradispro-resque-1If you're unsure which worker is stuck, or if the above doesn't resolve it, a full god restart will also cycle the resque workers:
god restartRetry the upload or export in the web app. If it's still stalling, move on to clearing the jobs queue.
In Dradis v4.18 or later, you can inspect the queue directly in the UI before going to the console — this works the same way for VM and Docker deployments. Click the cogwheel icon and select Background Jobs, or navigate manually to /pro/admin/jobs in your browser. The Queues tab shows any pending jobs, and the Failed Jobs tab shows anything that is stuck or has errored out.
On a Docker deployment, there's no need to hunt down and kill individual PIDs — the resque worker has its own container, so restarting it clears any stuck jobs:
docker compose restart resqueTo kill stuck resque processes from the console on a VM deployment, run the following as dradispro:
cd /opt/dradispro/dradispro/currentps aux | grep resqueA stuck worker will show output like this, with the job it is stuck on:
dradisp+ 12838 66.0 6.3 358416 130092 ? Rl 20:08 0:00 resque-1.27.4:
Processing dradis_export since 1547687319 [ActiveJob::QueueAdapters::ResqueAdapter::JobWrapper]Note down the process ID (the second column — 12838 in the example above) and kill it:
kill -9 12838Run the grep command again and repeat the kill -9 for any remaining stuck processes. You're done when all resque output shows Waiting rather than Processing:
dradisp+ 8747 0.0 5.5 324868 114892 ? Sl Jan14 0:24 resque-1.27.4:
Waiting for dradis_export,dradis_upload,dradis_migrate,dradis_projectOnce the workers are all in a waiting state, retry the upload or export in the web app.
If the restarts above resolve the stall but the problem keeps coming back, the resque logs are the place to look for the underlying cause.
On a Docker deployment, the resque log files live inside the resque container's filesystem, under /dradispro/logs/ — this is a different path from what docker compose logs resque shows you, which is only the container's stdout. List what's there, then view the file you need:
docker exec resque ls /dradispro/logs/docker exec resque cat /dradispro/logs/resque.logOn a VM deployment, check the following files as dradispro:
vi /var/log/god/dradispro-resque-1.logAny recurring errors or exceptions in these logs are worth capturing and sending to the Support team.
Puma is the application server that serves Dradis. While resque handles background jobs, Puma needs to be healthy for the web interface to respond at all. Docker deployments have no CIC at all, so there's only the one app container to worry about — on a VM deployment, Puma also serves the CIC (the Dradis Administrator Console), so there are two processes to check. A down Puma process can manifest as a 404 from nginx or a completely unresponsive UI even when the rest of the stack reports a clean status.
To restart the web server (puma), run:
docker compose restart appIf it's failing to start or keeps going down, the log files inside the app container will usually tell you why — this is a different path from what docker compose logs app shows you, which is only the container's stdout. List what's there, then view the file you need:
docker exec app ls /dradispro/logs/docker exec app cat /dradispro/logs/puma.err.logCheck how many Puma master processes are running:
ps aux | grep "[p]uma master"You should see two processes — one for the CIC and one for Dradis. If either is missing, try starting it via god:
god start dradispro-pumaOr restart both:
god restart dradispro-pumagod restart cic-pumaIf Puma is failing to start or keeps going down, the log files will usually tell you why. Check the following as dradispro:
Dradis:
CIC:
vi FILEPATHStill stuck after working through the steps above? Gather the Support bundle from /setup/support in your instance and send it to our Support team — we'll give you a hand. If you aren't able to reach the endpoint above to download the support bundle, you can get it from a terminal session to Dradis with:
On a Docker deployment, run:
docker exec app dp-support-bundle -o > /tmp/support-bundle.tar.gzOn a VM deployment, run:
/opt/dradispro/bin/dp-support-bundle -o > /tmp/support-bundle.tar.gzNext help article: My tool output won't upload! →
Loading form...
Your email is kept private. We don't do the spam thing.