A container starts, disappears, and comes back with the same error. The tempting fix is another restart. Before doing that, find out what made the process exit. A bad configuration, a full filesystem and a killed process can all produce the same Restarting status, but need different repairs. This guide is for a Linux home server running standalone Docker Engine and Docker Compose v2. The shell examples use Bash and GNU tools, as found on Ubuntu and Debian. Docker Desktop, Swarm and Kubernetes have different storage or restart behaviour. Start here: read the last application error, check the exit state, then compare it with events and host resources. Keep the container and its data in place while gathering evidence. Removing it can discard the logs and writable-layer files you need. On this page Capture the failure Read the status and exit code Check memory and exit code 137 Check storage, configuration and permissions Check dependencies and networking Apply a Compose fix c...
The dashboard was working yesterday. Today the database keeps restarting, an image update fails halfway through, and Docker says no space left on device . Somewhere in the search results, somebody suggests a prune command with every available flag. That is a good moment to slow down. The server may contain months of monitoring history, a password vault, or the only copy of an application configuration. A full disk needs a short investigation before it needs a cleanup command. This guide walks through that investigation on a Linux home server: identify the full filesystem, find the growing data, recover enough space to operate, and put a limit on whatever caused the problem. The quick answer: check both space and inodes, compare host usage with Docker’s inventory, and reclaim only data you have identified. Container logs, application data and build cache need different fixes. df -hT df -i docker system df -v docker ps -a --size These commands inspect the situation. If Docker is...