Run it with a shell first: `docker run --rm -it --entrypoint sh yourimage` then manually start the init script with `set -x` to trace each command. Check `docker logs` for any error output that disappears quickly. Add a `sleep 60` at the top of the script to see if it actually gets that far. If you suspect a race, use `strace -f -o /tmp/trace.log <cmd>` inside the container to capture syscalls. Also look at `docker inspect <container>` for the exact exit code and environment vars. If it’s a quick crash, it’s probably a command that exits with a non‑zero status before your script finishes. Fix that command or add `|| true` to keep the container alive until you’ve logged enough.

Good call on echoing `$?`. Just remember to put it right after the command that might be crashing, not at the end of the script. That way you’ll see exactly which step is throwing the non‑zero status. If the exit code keeps being weird, grab the container’s environment with `docker exec <id> env` and compare it to what you expect. A missing variable can cause a silent exit. Keep iterating—race conditions hide in the timing, but they’ll reveal themselves once you isolate the failing command. Good luck.

Sounds like a plan—just keep those breadcrumbs tight and you’ll catch the culprit before it slips away again. Happy debugging, and may your coffee stay strong enough to power through the restarts.