rcb backup: process container dies immediately; KEEP/PROCESS_COMMAND ignored; socket mount OK (v1.5.4)

Summary

Running rcb backup creates a “process container” which immediately exits and is removed. As a result, AUTO_BACKUP_ALL cannot perform discovery. RCB_KEEP_PROCESS_CONTAINER and RCB_PROCESS_COMMAND appear to be ignored.
Docker socket and DOCKER_HOST are correctly configured. A separately started debug/process container can access the Docker daemon via the socket. The issue affects only the rcb‑spawned child.
Important note about my abilities

I’m not a developer/ops person, just a smart‑home user (all this is produced by AI instructions). I can help test only if I get very precise, step‑by‑step instructions (exact commands to run and what output to share). Please provide explicit commands; otherwise I may not be able to assist effectively.
Environment

stack-back/rcb version: 1.5.4
Docker Compose: v2.33.1
Host OS: [fill in]
Project path: /docker/dozzle_agent (adjust if different)
Effective compose config (relevant service)
services:
backup:
image: ghcr.io/lawndoc/stack-back:v1.5.4
restart: unless-stopped
env_file:

• /docker/stack-back/stack-back.env
• /docker/restic/.env
  environment:
  AUTO_BACKUP_ALL: "True"
  DOCKER_HOST: unix:///var/run/docker.sock
  RCB_EXTRA_ENV: DOCKER_HOST=unix:///var/run/docker.sock
  RCB_EXTRA_MOUNTS: /var/run/docker.sock:/var/run/docker.sock:ro
  RCB_KEEP_PROCESS_CONTAINER: "true"
  RCB_PROCESS_COMMAND: /bin/sh -lc 'sleep 3600'
  volumes:
• /var/run/docker.sock:/var/run/docker.sock:ro
• /root/.ssh:/root/.ssh:ro
• cache:/cache

What happens

rcb backup logs:
“Starting backup container”
“Backup process container: ”
The process container immediately disappears (cannot inspect/exec into it).
Reproduction

Start the “steady” container:
docker compose up -d --force-recreate backup
Show versions:
docker compose exec -T backup rcb version
Output:
1.5.4
Docker Compose version v2.33.1
Trigger a run and capture the child name:
name=$(docker compose exec -T backup rcb backup 2>&1 | awk -F': ' '/Backup process container:/ {print $NF; exit}'); echo "$name"
Observe Docker events in parallel:
Terminal A:
docker events --filter 'type=container' --format '{{.Time}} {{.Status}} {{.Actor.Attributes.name}}' | grep -E 'create|start|die|destroy'
Terminal B:
docker compose exec -T backup rcb backup
Typical output (trimmed):
exec_create rcb backup dozzle_agent-backup-1
exec_start rcb backup dozzle_agent-backup-1
create compassionate_mcnulty
start compassionate_mcnulty
die compassionate_mcnulty
destroy compassionate_mcnulty
exec_die dozzle_agent-backup-1
Immediately after, the container name cannot be inspected:
docker inspect "$name" -> “No such object”
Error trace (from steady container)

The run fails with a Docker client error (unix socket):
docker.errors.DockerException: Error while fetching server API version: ('Connection aborted.', FileNotFoundError(2, 'No such file or directory'))
...
/restic-compose-backup/.venv/lib/python3.14/site-packages/docker/transport/unixconn.py: FileNotFoundError
Notes

In the steady container, DOCKER_HOST and socket are correct:
docker compose exec backup sh -lc 'echo $DOCKER_HOST; ls -l /var/run/docker.sock'
Output:
unix:///var/run/docker.sock
srw-rw---- ... /var/run/docker.sock
A separately defined “backup-debug” service with the same DOCKER_HOST and socket mount can access the Docker daemon (socket exists); host/socket setup is OK.
RCB_KEEP_PROCESS_CONTAINER and RCB_PROCESS_COMMAND seem to have no effect in v1.5.4 for the child. The child dies and is removed before I can inspect it.
Workaround used: a separate “backup-process” service that runs restic directly; snapshots/backup work via this approach.
Expected behavior

The rcb process container should be created with the given RCB_* settings (KEEP/PROCESS_COMMAND/EXTRA_*), receive DOCKER_HOST and the socket mount, remain running per KEEP/PROCESS_COMMAND, and allow AUTO_BACKUP_ALL discovery to complete.
Anything else

I’m happy to run any exact commands you provide to help debug (please give copy‑pasteable commands and what output you need). I can also test a candidate that ensures RCB_EXTRA_ENV/RCB_EXTRA_MOUNTS/KEEP/PROCESS_COMMAND are applied to the child before cleanup.

docker compose config.txt

rcb-backup-run.log.txt

dockr_events_log_create_start_die_destroy'.txt

docker compose ps
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
dozzle_agent-backup-1 ghcr.io/lawndoc/stack-back:v1.5.4 "./entrypoint.sh" backup 52 minutes ago Up 52 minutes
dozzle_agent-backup-debug-1 ghcr.io/lawndoc/stack-back:v1.5.4 "/bin/sh -lc 'sleep …" backup-debug 52 minutes ago Up 52 minutes
dozzle_agentwg amir20/dozzle:latest "/dozzle agent" dozzle-agent 2 hours ago Up 2 hours 0.0.0.0:7007->7007/tcp, [::]:7007->7007/tcp, 8080/tcp

docker compose exec -T backup env | grep '^DOCKER_HOST='
DOCKER_HOST=unix:///var/run/docker.sock

docker compose exec -T backup ls -l /var/run/docker.sock || echo "no socket"
srw-rw---- 1 root 119 0 Nov 17 15:05 /var/run/docker.sock

Start by reproducing the failure with the documented rcb backup command and observe the child container through Docker events. Trace the process-container creation and cleanup path, checking how RCB_EXTRA_ENV, RCB_EXTRA_MOUNTS, RCB_KEEP_PROCESS_CONTAINER, and RCB_PROCESS_COMMAND are applied; done means the child receives these settings and AUTO_BACKUP_ALL discovery completes.