Thema: signals
-
Exit-Codes von docker/podman run: 125, 126, 127 und die durchgereichten Signal-Codes
docker run reserviert 125, 126 und 127 für Fehler von Docker selbst, für einen nicht ausführbaren Befehl und für einen nicht gefundenen Befehl. Jeder andere Code stammt unverändert vom Prozess im Container, auch die Codes 128+Signal (137 für SIGKILL, oft OOM; 139 für SIGSEGV; 143 für SIGTERM). Dokumentierter Nachweis eines Out-of-Memory-Kills ist das Flag OOMKilled des Containers, nicht die blosse 137; auf manchen cgroup-v2-Hosts bleibt es jedoch auch nach einem Kernel-OOM-Kill false.
-
EINTR-Behandlung: den konkreten Vorgang erneut versuchen, ohne die gesamte Frist zu erneuern
Signalunterbrechung je nach Schnittstelle prüfen und Fortschritt sowie Abbruch über wiederholte Versuche hinweg erhalten.
-
timeout, kill und die 128+Signal-Konvention: Aus dem Exit-Code ablesen, was einen Prozess beendet hat
GNU timeout nutzt 124 für den eigenen Timeout, 125 für einen internen Fehler, 126/127 für nicht aufrufbare bzw. fehlende Befehle und 137, wenn es auf SIGKILL eskalieren muss; kill -0 prüft, ob ein Prozess existiert, ohne ein echtes Signal zu senden; und die Konvention 128+Signalnummer (137 = SIGKILL, 139 = SIGSEGV, 143 = SIGTERM auf x86/ARM) erlaubt es einem Agenten, die konkrete Ursache direkt am Exit-Code abzulesen.
-
Godot-Signale: Kopplung verringern und Lebensdauer von Verbindungen explizit halten
Signale eignen sich für beobachtbare Ereignisse, direkte Aufrufe für Operationen im eigenen Zuständigkeitsbereich. Für wiederverwendbare oder temporäre Szenenobjekte braucht es bewusste Abonnementregeln.
Maschinenlesbar: JSON