Die erste Version unseres realen Docker-Installationsscripts endete mit Exit Code 141, obwohl die Docker-Paketinstallation funktionierte. Ursache war nicht Docker Engine: set -o pipefail war aktiv und die reine Anzeige-Pipeline 'apt-cache policy docker-ce | head -n 20' führte beim frühen Ende von head zu SIGPIPE im Upstream. Mit sed -n lief das Script weiter; final wurden Docker 29.7.2 und Compose v5.4.0 bestätigt.
set -o pipefail
apt-cache policy docker-ce | head -n 20
↓
head endet früh
Upstream erhält SIGPIPE
128 + SIGPIPE(13) = exit 141
↓
apt-cache policy docker-ce | sed -n '1,20p'
↓
Script läuft weiterNach der Paketinstallation kürzte das Script apt-cache policy mit head. Durch pipefail machte der Upstream-SIGPIPE die Pipeline fehlerhaft.
Exit 141 bedeutete daher nicht, dass Docker selbst scheiterte.
set -o pipefailapt-cache policy docker-ce | head -n 20echo $?Shells melden Signalende häufig als 128 plus Signalnummer. SIGPIPE ist 13, daher 141.
head schließt die Pipe früh; der Upstream kann SIGPIPE erhalten.
Ohne pipefail zählt oft der Status des letzten Befehls. Mit pipefail beeinflusst ein fehlerhafter Upstream die Pipeline.
Mit set -e kann dadurch das ganze Script enden.
set -euo pipefailapt-cache policy kann mehr ausgeben als head liest. Nach 20 Zeilen schließt head seine Pipe-Seite und der Producer kann SIGPIPE erhalten.
Das ist ein Pipeline-Lifecycle-Problem.
apt-cache policy docker-ce | head -n 20Die Zeile wurde durch apt-cache policy docker-ce | sed -n '1,20p' ersetzt. sed kann den Input weiter konsumieren und nur gewünschte Zeilen ausgeben.
pipefail blieb erhalten, SIGPIPE verschwand.
apt-cache policy docker-ce | sed -n '1,20p'Nach Exit 141 zeigen docker --version, Compose-Version, Service-Status und hello-world den echten Docker-Zustand.
Der reale Finalscreen bestätigte Docker 29.7.2 und Compose v5.4.0.
docker --versiondocker compose versionsystemctl is-active dockerdocker run --rm hello-worldInformationsausgaben von kritischen Installationsschritten trennen.
Gezielte Fallbacks nutzen, aber echte apt/docker-Fehler nicht pauschal mit || true verstecken.
Nach der Korrektur wurden Docker Engine, Compose und Portainer real bestätigt. Ursache war die Bash-Pipeline, nicht Docker Engine.
Bei ähnlichem 141 den letzten Pipeline-Befehl ermitteln.
In diesem Fall SIGPIPE: 128 + Signal 13.
Nein; finale Prüfungen zeigten funktionierendes Docker.
apt-cache policy docker-ce | head -n 20.
Es übernimmt Upstream-Fehler in den Pipeline-Status.
Das Script kann bei non-zero Pipeline enden.
Es schließt die Pipe nach gewünschter Zeilenzahl.
head durch sed -n '1,20p' ersetzen.
Nicht pauschal; es kann echte Fehler verbergen.
Version, Compose, Service-Status und hello-world.
Nein; verschiedene SIGPIPE-Pipeline-Szenarien sind möglich.
Es kann Input weiter konsumieren und nur ausgewählte Zeilen drucken.
Die Pipeline direkt vor Exit 141.
Ja; apt update und echte Paketinstallation separat prüfen.
Ja, besonders in non-interaktiven Bash-Scripts mit pipefail.
Docker und Self-Hosted-Dienste auf EKA-Sunucu-Linux-VPS betreiben.
Aktualisiert: 10.08.2026