Alle Docker Container starten neu, wenn was großes kopiert wird

[update-freak]

Hi zusammen,

ich habe die Situation, dass wenn ich z.B. was großes (ca. 80GB große Datei) von meinem NAS auf den PC kopiere die Docker container währenddessen neu starten.
Soweit ich weiß gab es diesen Fall schon einmal, wo JDownloader2 was großes entpackt hat.
Weiß jemand wie ich das nun am besten eingrenze woran das liegen kann?
Sieht für mich so aus als tritt das nur bei großer Belastung auf.

DS716+
14% Feier Speicherplatz (=1,5TB), Btrfs, RAID 0
RAM 8GB (erweitert)

 

[Mahoessen]

hi, lass mal während des Kopierens den Ressourcen Monitor laufen und schau mal drauf, ansonsten: wie viele Container , was steht im Container Manager Log?, welches DSM, welche Updates usw...

 

[update-freak]

ok, mach ich.

Anzahl Container: 47
DSM: 7.2.2-72806 Update 3
Das Prodikoll vom Container Manager hatte nur die Info drin, dass die Container gestoppt wurden.

 

[Mahoessen]

was steht im DSM-Protokollcenter zum Absturzzeitpunkt?
Einbindung der DS über SMB?

 

[update-freak]

ist über SMB.
Im Protokollcenter waren die logs gelöscht. Melde mich nochmal wenn es wieder auftritt was in den logs steht

 

[Benie]

Nur mal so eine Überlegung von mir. 47 Container, das ist ja doch eine Menger, wieviel RAM hast Du denn verbaut? evtl. mal den RAM wärend dem Kopieren von so großen Datenmengen beobachten und wer da wieviel verbraucht oder nicht verbraucht, bzw. zurr Verfügung gestellt bekommt. Evtl. mit RAM Zuweisung arbeiten.

 

[Mahoessen]

wieviel RAM

8gb, steht oben, dafür habe ich die 47 überlesen
je nach Containern ist die DS sicherlich am Anschlag, wenn dann noch größere Mengen geswappt werden müssen .
=> alle Container stoppen, und den Kopiervorgang mal probieren

 

[rmayergfx]

Hi zusammen,

ich habe die Situation, dass wenn ich z.B. was großes (ca. 80GB große Datei) von meinem NAS auf den PC kopiere die Docker container währenddessen neu starten.
Soweit ich weiß gab es diesen Fall schon einmal, wo JDownloader2 was großes entpackt hat.
Weiß jemand wie ich das nun am besten eingrenze woran das liegen kann?
Sieht für mich so aus als tritt das nur bei großer Belastung auf.

DS716+
14% Feier Speicherplatz (=1,5TB), Btrfs, RAID 0
RAM 8GB (erweitert)

Welches Modell ist das genau? 716+II oder 716, erkennbar am Prozessor:
https://kb.synology.com/de-de/DSM/tutorial/What_kind_of_CPU_does_my_NAS_have#x16-series

Welche DSM Version ist installiert?

Welche RAM Module wurden für das Aufrüsten benutzt, da gab es durchaus Probleme mit Abstürzen von Containern.

47 Container ist schon sehr sehr viel für diese kleine Syno, was hast du denn da alles auf laufen?

 

[haydibe]

Ich gehe davon aus, dass hier der Container Manager unter DSM7.2 zum Einsatz kommt.

Mit folgendem Befehl kann man sich die Logs der Docker Engine anzeigen lassen:

sudo journalctl -xu  pkg-ContainerManager-dockerd.service

Dort sollte zu erkennen sein, ob die Container bspw. OOM-Killed werden, wenn der Kiste der Arbeitsspeicher ausgeht.

 

[update-freak]

Welches Modell ist das genau? 716+II oder 716, erkennbar am Prozessor:
https://kb.synology.com/de-de/DSM/tutorial/What_kind_of_CPU_does_my_NAS_have#x16-series

Welche DSM Version ist installiert?

Welche RAM Module wurden für das Aufrüsten benutzt, da gab es durchaus Probleme mit Abstürzen von Containern.

47 Container ist schon sehr sehr viel für diese kleine Syno, was hast du denn da alles auf laufen?

Ist die 716+ (also nicht +II).
DSM: 7.2.2-72806 Update 3
Container:

1. acme.sh
2. AdGuardHome
3. Audiobookshelf
4. Baikal
5. Beszel
6. Beszel-Agent
7. ChangeDetection
8. DokuWiki
9. Emby
10. Filebot
11. Forgejo
12. FreeFileSync
13. FreshRSS
14. github_issues_rss (selbst mit ChatGPT erstellt)
15. rustdesk-hbbr
16. rustdesk-hbbs
17. JDownloader2
18. Joplin
19. Joplin-db
20. loggifly
21. NEWeasyepg
22. ntfy
23. Paperless-ngx
24. Paperless-ngx-grotenberg
25. Paperless-ngx-redis
26. Paperless-ngx-tika
27. PDFDing
28. PhotoPrism
29. PhotoPrism-db
30. PodFetch
31. Portainer
32. Stirling-PDF
33. syncstorage
34. syncstorage-db
35. Syncthing
36. Tandoor
37. Tandoor-db
38. Tandoor-nginx
39. unbound
40. upvote-rss
41. Vaultwarden
42. wanderer-db
43. wanderer-search
44. wanderer-web
45. Watchtower
46. ZeroTier-controller
47. ZeroTier-ui

Kann ich irgendwo nachschauen welche RAM-Module verwendet wurden?

 

[update-freak]

Ich gehe davon aus, dass hier der Container Manager unter DSM7.2 zum Einsatz kommt.

Mit folgendem Befehl kann man sich die Logs der Docker Engine anzeigen lassen:

sudo journalctl -xu  pkg-ContainerManager-dockerd.service

Dort sollte zu erkennen sein, ob die Container bspw. OOM-Killed werden, wenn der Kiste der Arbeitsspeicher ausgeht.

gerade ist es nochmal passiert.
hier ist mal die log-Datei vom Inhalt des Befehls.

 

[ctrlaltdelete]

Du überforderst die DS716+, die Kopieraktion braucht zuviel Ressourcen:

Symptome aus dem Log (analysiert mit Chatgpt:​

• broken pipe, stream copy error: reading from closed fifo, Healthchecks timeouts
  ⇒ Prozesse verhungern oder hängen sich auf, weil das System nicht mehr reagiert.
• panic: invalid memory address or nil pointer dereference
  ⇒ typischer Folgefehler, wenn ein interner Thread keine Rückmeldung mehr bekommt oder durch RAM-Mangel ins Leere greift.
• Container reagieren nicht mehr auf SIGTERM und müssen gekillt werden
  ⇒ Das passiert oft bei I/O-Warteschlangen oder wenn Docker auf langsame Dateisysteme trifft.

Technische Engpässe deiner DS716+​

Flaschenhals	Erklärung
Nur Dual-Core CPU (Intel N3160)	Langsam bei parallelem I/O + Docker-overhead
8 GB RAM	Viel für DSM, wenig wenn Docker + Kopiervorgang + ggf. SMB + Monitoring gleichzeitig laufen
Langsames Storage Backend	Wenn du z. B. große Dateien über SMB/NFS + gleichzeitig Container auf Volume1/2 laufen hast, werden Queue-Tiefe und Latenzen schnell kritisch
Kein ZRAM / kein Swap?	Bei RAM-Mangel stirbt der Daemon gnadenlos – oder du bekommst OOMs
Btrfs Overhead	Kompression, Snapshots, Checksumming kosten ordentlich CPU bei hohem Durchsatz

Warum es knallt:​

1.​

• Btrfs braucht mindestens 10–20 % freien Speicher, um intern Metadatenblöcke, Checksums und Snapshots performant zu verwalten.
• Unter 15 % freiem Platz kann es bei RAID 0 zu Fragmentierung, Metadaten-Wirrwarr und Reallocation-Fails kommen → starke I/O-Latenz.
• Das erklärt die Docker-Fehler wie stream copy error, healthcheck timeout und am Ende sogar den Daemon-Crash (SIGSEGV).

2.​

• Schon ein kleiner Dateisystemfehler kann alle Container oder Dienste killen, wenn ein Volume hängt.

3.​

• Docker speichert Container-Overlay-Images auf dem Btrfs-Layer.
• Bei hoher I/O (Kopieren großer Daten) gibt es Locking-Probleme → Docker-Prozesse bleiben hängen → broken pipe → dockerd kippt.

 

[haydibe]

Ich hab mir das log auch eingesehen. Die ersten Einträge bis hier sind leider schon alles nur Fehlerreaktionen, aber zeigen keinen Hinweis zum Auslöser:

Jun 27 23:10:18 NAS systemd[1]: Starting Docker Application Container Engine...

Man erkennt nur, dass die Docker Engine alle viere von sich gestreckt hat.
Beim Start der Docker Engine räumt er erstmal Liegengebliebenes von vor der Beendigung auf. Die Shims sind quasi das Bindeglied zwischen Container und Docker selbst - diese sind jetzt nicht mehr gültig und werden abgeräumt.

Diese Logeinträge wirken so, als wenn Synology in ihrer Docker Engine irgendwo eine Verbiegung durchgeführt hat, aber diese nicht überall durchgezogen hat:

Jun 27 23:13:18 NAS dockerd[4282]: time="2025-06-27T23:13:18.688140741+02:00" level=warning msg="Failed to delete conntrack state for 192.168.16.2: invalid argument"

Dann erkennt man noch das Problem überlastet ist und nicht mit dem DNS-Server Sprechen kann:

Jun 27 23:18:05 NAS docker[4282]: time="2025-06-27T23:18:05.357502361+02:00" level=error msg="[resolver] failed to query DNS server: 192.168.178.27:53, query: ;changedetection.io.\tIN\t A" error="read udp 192.168.240.2:59586->192.168.178.27:53: i/o timeout"

Ein oder mehrere andere Prozesse sorgen dafür, dass der DNS-Request im Treiber/Netzwerkinterface verhungert, weil es nicht rechtzeitig mit der Hardware kommunizieren kann. Das ist ein Folgeproblem der Überlastung.

Und schon während die Engine den Start abgeschlossen hat, ist sie schon wieder krepiert:

Jun 27 23:22:28 NAS systemd[1]: Started Docker Application Container Engine.

Riecht nach zu viel Belastung für zu wenig Blech...

Das Wiederbeleben von 47 Containern gleichzeitig wird die Sache auch noch verschlimmern, da die Prozesse gerne beim Start einen Peak bei CPU und RAM Belegung haben (kommt natürlich auf den Container an, ist aber nicht unüblich).

 

[update-freak]

vielen Dank euch für die Analyse
Muss dann echt mal schauen welchen Container ich wirklich brauche oder durch welches leistungsstärkeres Gerät ich mein NAS ersetzen kann.

 

[ctrlaltdelete]

Bei so vielen Containern würde ich auf ein Gerät setzen mit SSD und HDD. Dann kannst du die Container alle auf SSD laufen lassen.
Edit UGREEN DXP4800 oder DXP4800 Plus

 

[Benie]

Ich habe aktuell auf einer UGREEN, DXP4800Plus mit 64GB RAM, 28 Container am laufen, das merkt die überhaupt nicht. Alle Container zusammen liegen bei ca 6GB RAM Nutzung, CPU Auslastung für das OS und alle Container im Idle unterhalb 3%.

Man sieht die DXP hat überhaupt keine Probleme damit, auch wenn das jetzt nur im Idle ist.