Am 21.02.25 um 20:15 schrieb Daniel Leidert:
Am Montag, dem 17.02.2025 um 20:20 +0100 schrieb N. Schwirz:
Du kannst hier entweder in der systemd .service-Datei das Arbeitsverzeichnis definieren, z.B.
[Service] User=meinuser Group=docker WorkingDirectory=/root/git/gitlab
Oder du gibt dem docker-compose-Befehl den Pfad zur docker-compose- Datei mit. Ich würde erstes empfehlen.
@daniel: Von welcher systemd service-Datei redest du? Es gibt keine und braucht keine service-Datei um docker Container (oder einen compose Verbund) zu starten! Das ist bei podman anders, weil es dort (normalerweise) keinen Daemon gibt, der alle Container verwaltet!
@norman: Bei Docker gilt im Normalfall, also bei einer Standardinstallation ohne eigene Anpassungen an den verschiedenen beteiligten Diensten, dass a) der Docker Daemon beim Start des Rechners auch gestartet wird b) der Docker Daemon beim Start alle Container startet, die eine passende restart-policy haben
Wenn das nicht funktioniert, startet dein Docker vielleicht nicht beim Systemstart. Vielleicht hast du nicht den service, sondern den socket aktiviert. Der sorgt erst nach einem Zugriff auf den Docker-Socket dafür, dass der Docker Daemon startet. Das passiert aber nicht automatisch beim Systemstart. Wenn das der Fall ist, müssten deine compose Container (wenn sie restart gesetzt haben) aber starten, sobald du auf den Docke-Socket zugreifst, z.B. mit `docker ps`.
Also kontrollier nach einem Systemstart a) ob der Docker Service läuft b) mit `docker ps` welche Container laufen c) mit `docker ps -a` welche Container gestoppt sind
Wenn das Systemstartverhalten OK ist, brauchst du nicht mehr das System neu starten um dein Fehlerbild zu untersuchen. Es reicht ein Restart des Docker-Service.
Die RestartPolicy für einen laufenden Container fragst du mit diesem Befehl ab: docker inspect -f "{{ .HostConfig.RestartPolicy }}" ct-name-or-id
Compose verhält sich nicht anders als manuell gestartete Container!
Vielleicht hast du auch in deinem compose-Verbund die Abhängigkeiten nicht korrekt definiert und die Container werden zwar beim Start von Docker gestartet, aber in der falschen Reihenfolge und das kann je nach Containerverbund dazu führen, dass sie beendet werden, weil eine Gegenstelle nicht innerhalb eines Timeouts antwortet oder Ähnliches.