Bug: access-log-cleanup fails nightly in Docker Swarm — hardcoded container name 'dokploy-traefik' doesn't match swarm task name

[tyler-b4innova]

Summary

The nightly access-log-cleanup job (in packages/server/src/utils/access-log/handler.ts) runs:

await execAsync("docker exec dokploy-traefik kill -USR1 1");

In Docker Swarm mode the traefik container is named dokploy-traefik.1.<task-id> (e.g. dokploy-traefik.1.xk3abcdef123), not dokploy-traefik. The docker exec call therefore fails every night with a "No such container" error.

Version

Dokploy v0.29.4 (also present in v0.29.8 — handler.ts unchanged through current canary).

Environment

• Deployment mode: Docker Swarm (single-node or multi-node)
• Dokploy running as a swarm service (dokploy-traefik is a swarm service, not a plain container)

Reproduction

1. Deploy Dokploy in Docker Swarm mode (the standard install on any VPS).
2. Wait for the nightly access-log-cleanup cron to fire (default 0 0 * * *).
3. Observe Dokploy service logs: Error during log cleanup: Error: No such container: dokploy-traefik.
4. The log rotation (tail -n 1000 ... > ....tmp && mv ...) succeeds — it moves the file, changing the inode — but the kill -USR1 signal is never delivered, so Traefik continues writing to the now-deleted inode.
5. The host-side access.log becomes a stale, frozen 1000-line decoy. Real traffic logs accumulate only inside /proc/<traefik-pid>/fd/<n> until the container restarts.

Expected behaviour

Traefik receives SIGUSR1 after the log rotation, reopens access.log on the new inode, and log rotation works correctly.

Actual behaviour

docker exec dokploy-traefik kill -USR1 1 exits non-zero every night. Traefik writes to a deleted-file handle indefinitely. The on-disk access.log is permanently frozen at 1000 lines (the last successful rotation before this is noticed).

Suggested fix

Resolve the running task container name dynamically before signalling, using either:

Option A — label filter (preferred):

docker ps -q --filter "name=dokploy-traefik" --filter "status=running" | head -n 1

Then docker exec <id> kill -USR1 1.

Option B — Docker API label filter (works in both swarm and non-swarm):

docker ps -q \
  --filter "label=com.docker.swarm.service.name=dokploy-traefik" \
  --filter "status=running" | head -n 1

Option C — use docker kill --signal USR1 directly on the service:

docker kill --signal USR1 $(docker ps -q --filter "name=dokploy-traefik" --filter "status=running" | head -n 1)

All three avoid the hardcoded name assumption and work correctly in both plain-Docker and Swarm deployments.

Related code

packages/server/src/utils/access-log/handler.ts, line with await execAsync("docker exec dokploy-traefik kill -USR1 1").

[dosubot]

Hi @tyler-b4innova! I'm Dosu and I'm helping the Dokploy team.

This is a valid finding, but there's important architectural context here: PR #1371 (March 2025) intentionally migrated Traefik from a Docker Swarm service to a standalone container [1]. After that migration, Traefik is expected to run as a plain Docker container named dokploy-traefik — not as a Swarm service task — even when Dokploy itself orchestrates application services via Swarm.

The relevant code in handler.ts performs a two-step rotation [2]:

1. Truncates the log to the last 1000 lines via tail -n 1000 ... > ....tmp && mv ...
2. Sends SIGUSR1 via docker exec dokploy-traefik kill -USR1 1

If your Traefik container is showing up as dokploy-traefik.1.<task-id>, that suggests it's still running as a Swarm service rather than a standalone container. This could happen if:

• You upgraded from an older Dokploy version that originally deployed Traefik as a Swarm service and the migration to standalone didn't complete.
• Something in your environment re-created Traefik as a Swarm service.

That said, your suggested fix (Option A — using docker ps -q --filter "name=dokploy-traefik" --filter "status=running" | head -n 1) would make the code resilient to both deployment modes and is a reasonable defensive improvement. The name filter does a substring match, so it would resolve both dokploy-traefik (standalone) and dokploy-traefik.1.xk3abcdef123 (swarm task).

As an immediate workaround, you could check whether recreating Traefik as a standalone container (which is the expected post-v0.17 architecture) resolves the issue for your deployment.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.