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.
