entrypoint.sh ignores container command: faraday-default-worker runs a second server instead of a Celery worker

[gl0balw0rk]

Issue Type

• Bug Report

Faraday version

Faraday v5.23.0 (Docker image faradaysec/faraday:latest) — also present in current master (commit b6a06c56d)

Component Name

Docker deployment / Celery worker (report ingestion pipeline)

Steps to reproduce

1. Fresh installation following the official guide:

   curl -O https://raw.githubusercontent.com/infobyte/faraday/master/docker-compose.yaml
   docker compose up -d

2. Authenticate faraday-cli and create a workspace:

   faraday-cli auth
   faraday-cli workspace create test

3. Run any tool through the CLI (or upload any report via Web UI / API):

   faraday-cli tool run "nmap -sV 127.0.0.1"

   The CLI reports success: Sending data to workspace: test → Done.

4. Check results:

   faraday-cli host list

Expected results

Imported hosts/services appear in the workspace shortly after upload.

Debugging tracebacks (current results)

host list stays empty forever. Investigation shows the report ingestion pipeline is broken because the faraday-default-worker container never runs a Celery consumer:

• Server logs show the report is received and queued:

  bulk_create.py:1249 - post()  Faraday objects sent to celery in bulk for workspace <Workspace 1>
  

• Tasks accumulate in Redis, never consumed:

  $ docker exec faraday_redis redis-cli LLEN celery
  9
  $ docker exec faraday_worker celery -A faraday.server.celery_worker:celery inspect ping
  Error: No nodes replied within time constraint

• Worker container logs show it started a second faraday-server, not a worker:

  Starting Faraday server ...
  Server initialized for gevent.
  WARNING - Faraday Server is already running. PID: 21
  

Root cause: docker/entrypoint.sh ignores the command passed by docker-compose. The compose file declares command: ["faraday-worker"] for the faraday-default-worker service, but the entrypoint ends with a hardcoded server start and never executes "$@":

# docker/entrypoint.sh (last lines)
echo "$(date) Starting Faraday server ..."
faraday-server --bind 0.0.0.0

So every container using this image runs faraday-server, regardless of the command. There is no Celery consumer anywhere in the stack, so every report uploaded via CLI, Web UI, API, or agents is queued in Redis and silently never imported. Related: since gevent is used by the server, the prefork Celery pool is also known to conflict (see #527) — the faraday-worker-gevent entrypoint exists in pyproject.toml and should be used.

Proposed fix:

# docker/entrypoint.sh (last lines)
if [ $# -gt 0 ]; then
    echo "$(date) Starting $@ ..."
    exec "$@"
else
    echo "$(date) Starting Faraday server ..."
    exec faraday-server --bind 0.0.0.0
fi

and in docker-compose.yaml, set the worker service command to ["faraday-worker-gevent"].

Verified locally: with both changes, the worker boots a real consumer (celery@<host> v5.4.0, inspect ping → 1 node online), the Redis queue drains to 0, and previously uploaded reports appear in the workspace.

Screenshots

N/A — evidence above is from server/worker logs and Redis.

Environment information

Configuration files

Default docker-compose.yaml from master, unmodified.

Reports/Extra data

N/A

OS

Arch Linux

[ignaciosoto93]

Thanks for the report. I reviewed it against the current Docker installation guide and also validated the workaround end-to-end on an isolated test stack.

The documented way to run Faraday is still Docker Compose:

curl -O https://raw.githubusercontent.com/infobyte/faraday/master/docker-compose.yaml
docker compose up -d

and that setup is supposed to bring up:

• faraday-server
• db
• redis
• faraday-default-worker as the Celery background worker

What I confirmed on the current codebase is that the deployment model is correct, but the current implementation has a bug in the worker startup path.

On the default Compose setup:

• the worker container starts faraday-server instead of a Celery worker
• celery inspect ping returns no responders
• uploading a report returns ok, but the queue keeps growing and nothing is imported

I then tested the following workaround on the faraday-default-worker service:

faraday-default-worker:
  entrypoint: ["faraday-worker"]
  command: []

With that in place:

• the worker starts as a real Celery consumer
• celery inspect ping returns pong
• the same Nmap test report is consumed successfully
• the Redis queue drains
• hosts/services appear in the workspace as expected

So as a temporary workaround, overriding the worker service entrypoint to faraday-worker is a valid fix for the current Compose setup.

The engineering team should address the underlying issue so the default documented Compose flow works without requiring this override.

[ignaciosoto93]

Solved on version v5.23.2