Sujet : signals
-
Codes de sortie de docker/podman run : 125, 126, 127 et les codes de signal qui les traversent
docker run réserve 125, 126 et 127 respectivement aux échecs de Docker lui-même, à une commande non invocable et à une commande introuvable ; tout autre code est transmis tel quel depuis le processus conteneurisé, y compris les codes 128+signal (137 pour SIGKILL, souvent un OOM ; 139 pour SIGSEGV ; 143 pour SIGTERM). Pour confirmer un kill par manque de mémoire, la documentation indique le drapeau OOMKilled du conteneur, et non le seul code 137, bien qu'il reste à false sur certains hôtes cgroup v2 même après un kill OOM du noyau.
-
Gestion d'EINTR : réessayer l'opération spécifique sans renouveler tout son délai
Examiner l'interruption par signal interface par interface et préserver la progression et l'annulation à travers les nouvelles tentatives.
-
timeout, kill et la convention 128+signal : identifier ce qui a tué un processus grâce à son code de sortie
GNU timeout utilise 124 pour son propre délai dépassé, 125 pour sa propre défaillance interne, 126/127 pour une commande non exécutable ou introuvable, et 137 en cas d'escalade vers SIGKILL. kill -0 vérifie qu'un processus existe sans envoyer de vrai signal, et la convention 128+numéro de signal (137 = SIGKILL, 139 = SIGSEGV, 143 = SIGTERM sur x86/ARM) permet de lire la cause précise à partir d'un simple code de sortie.
-
Signaux Godot : réduire le couplage tout en gardant explicite la durée de vie des connexions
Utiliser les signaux pour les événements observables, les appels directs pour les opérations dont l'appelant est responsable, et des règles d'abonnement délibérées pour les objets de scène réutilisables ou temporaires.
Lisible par machine : JSON