Controlli che non possono fallire: cinque falsi positivi da una settimana di automazione Mac

Una sola regola ci avrebbe risparmiato quasi una settimana. Prima di fidarti di un controllo, chiediti cosa stampa quando la cosa è rotta. Se la risposta è "la stessa cosa", non hai un controllo. Hai una decorazione con scritto OK.

Eccone cinque che abbiamo trovato in una settimana. Tutti su macOS, tutti in automazioni che giravano senza problemi da mesi. Ognuno ha dato una risposta sbagliata con grande sicurezza. E ognuno ha mandato una persona a riparare qualcosa che non era rotto.

1. L’aggiornamento che non stava girando

Una macchina sembrava lenta a tornare dopo un riavvio. Un rapido pgrep -f softwareupdate ha trovato una corrispondenza. Così lo script ha segnalato un aggiornamento software in corso, e noi abbiamo aspettato.

Non c’era nessun aggiornamento. softwareupdated è un daemon sempre presente su ogni Mac, e una ricerca per sottostringa lo trova che stia succedendo qualcosa o no. Se n’è accorto il proprietario della macchina con una domanda semplice: non dovrebbe esserci nessun aggiornamento, quindi qual è il problema? Il controllo non aveva risposta, perché non ne aveva mai avuta una.

La soluzione è cercare ciò che un aggiornamento in corso lascia dietro di sé. Un download in corso o un’attività del disco costante sono prove. Il nome di un processo sempre presente no.

2. L’Xcode copiato in zero secondi

Cloniamo Xcode tra le macchine inviando un archivio tar via SSH. In un’esecuzione il flusso passava da un portatile rimasto senza memoria. Il lato che inviava è morto. Il tar -xf - che riceveva ha letto uno stream vuoto, non ha estratto nulla ed è uscito con zero. Lo script ha stampato XCODE_COPIED.

Non si era spostato nemmeno un byte. L’exit code era onesto su ciò che era stato chiesto a tar, cioè estrarre quello che arrivava. Non era arrivato niente.

# what we checked
tar -xf - -C /Applications && echo XCODE_COPIED

# what we should have checked
du -sh /Applications/Xcode.app          # 3.8G, or it did not happen
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -version

3. Il permesso segnalato come concesso

macOS protegge la registrazione dello schermo con un privilegio che solo una persona o un profilo MDM possono concedere. Lo strumento kickstart di Apple stampa un avviso chiaro quando il privilegio manca. La nostra verifica cercava quell’avviso. Non trovandolo, segnalava il privilegio come concesso.

Quando lo strumento non ha alcun privilegio, non stampa nulla. Nessun avviso, niente di niente. L’assenza di un avviso sembrava esattamente un successo. La storia completa è in il Mac che ti fa entrare e non ti mostra niente. La soluzione è stata smettere di chiedere il parere allo strumento e campionare invece pixel reali dal framebuffer.

4. Il desktop segnalato come morto

Per confermare che un utente fosse connesso all’interfaccia grafica, controllavamo chi possedeva /dev/console. Su una macchina nuova risultava root, quindi concludevamo che nessuno fosse connesso. Poi abbiamo controllato la macchina di un cliente, con un utente connesso da due giorni. Anche lì risultava root.

Per circa dieci minuti il desktop di un cliente pagante è stato segnalato come fuori uso. Stava benissimo. Il proprietario del device node semplicemente non significa ciò che pensavamo. who mostra una riga console solo quando esiste una sessione, ed è quello che la nostra telemetria riporta oggi.

5. L’errore che era una costante

Una macchina con una nuovissima versione major di macOS non faceva il login automatico. Il comando di Apple sysadminctl -autologin set restituiva SACSetAutoLoginPassword error:22. Nuovo OS, nuovo errore, conclusione ovvia: la nuova release aveva rotto il login automatico via script.

Poi abbiamo eseguito lo stesso comando su una macchina sana, una major indietro, dove il login automatico funzionava da settimane. Stesso errore. Il comando fallisce in modo identico su sistemi sani e rotti, quindi non diceva nulla né degli uni né degli altri. La vera causa era una condizione temporanea del primo avvio. La diagnosi sicura era sbagliata, e il controllo di confronto l’ha smentita in meno di un minuto.

La regola, e due corollari

Tutti e cinque falliscono la prima domanda. Abbiamo passato quattro giorni a inseguirli. Nessuno dei sistemi sottostanti era rotto nel modo che i controlli dicevano.

Cosa è cambiato

Il controllo dello schermo campiona il framebuffer e conta i colori. Il controllo della sessione usa who e finisce nella telemetria. Così una macchina ferma alla finestra di login fa scattare un allarme invece di sembrare sana. Le copie vengono verificate per dimensione ed eseguendo il binario copiato. E nessun guasto riceve una causa finché lo stesso controllo non è stato eseguito su qualcosa che sappiamo funzionare. Niente di tutto ciò è geniale. È sempre la stessa domanda, fatta prima di scrivere il controllo e non dopo che ha mentito.