nanoPi r6c crashes when starting containers (docker compose up -d)

[plix1014]

I have a nanoPi R6C running with dietpi v9.6.1 (debian bookworm) with several docker containers with no issues. In December the nanopi started to crash during container startup. I could not figure out, what was the reason. After several retries, I could get my services up and running again. In fact, I replaced it for two weeks with the old raspberryi Pi4 pihole (no docker). When I switched back, It worked without any issue, although I did not change anything (shutdown unplug, replace with pi4, two weeks later unplug pi4 and connect nanopi and boot).
Since then I had zero issues. Now it starts again. I have no glue what is the reason. I just get disconnected when starting the containers.
Also on the console I do not see an obvious error.

see 01_docker_pihole_start.txt: docker compose
see 02_nanopi_r6c_crash_reboot.txt: debug console output.

Any idea what could trigger the crash?

I also have three raspberry pi (4,5) with docker containers (debian bookworm). Non of them crashed once when starting a container.

02_nanopi_r6c_crash_reboot.txt
01_docker_pihole_start.txt

[MichaIng]

client_loop: send disconnect: Broken pipe

This error message is no crash and has nothing to do directly with Docker/the container: It is output from your SSH client, that it got connected from the OpenSSH server. You also see that you land on the client side console after the error. Check your OpenSSH config. Here is some info about the two relevant settings to check: https://www.tecmint.com/client_loop-send-disconnect-broken-pipe/
Probably the container startup takes very long?

[plix1014]

Well, if I'm logged in from remote, the last messages is the broken pipe, which indices that I lost the connection.
After relogin, I see, that the server rebooted. The container than cannot be started, because some "docker-proxy ..." processes are already running. So I need to kill them (systemctl restart docker). When I try to start the container, I get disconnected again.
The startup of the container, if it works, is quit quick, so no long startup time.

[MichaIng]

Sorry for the late reply. Does the issue persist?

Hmm, if the some docker-proxy service runs already, were the containers maybe started automatically at boot, together with the docker.service?

Maybe enabling persistent system logs can help to check what went wrong:

dietpi-software uninstall 103 # this uninstalls RAM logging
mkdir /var/log/journal # systemd logs to disk automatically if this dir exists
reboot