Prüfungen, die nicht fehlschlagen können: fünf Fehlalarme aus einer Woche Mac-Automatisierung

Eine Regel hätte uns fast eine Woche gespart. Bevor Sie einer Prüfung vertrauen, fragen Sie, was sie ausgibt, wenn die Sache kaputt ist. Lautet die Antwort "dasselbe", haben Sie keine Prüfung. Sie haben eine Dekoration, auf der OK steht.

Hier sind fünf, die wir in einer Woche gefunden haben. Alle unter macOS, alle in Automatisierung, die monatelang klaglos lief. Jede lieferte selbstsicher eine falsche Antwort. Und jede schickte einen Menschen los, um etwas zu reparieren, das nicht kaputt war.

1. Das Update, das nicht lief

Eine Maschine schien nach einem Neustart langsam zurückzukommen. Ein schnelles pgrep -f softwareupdate fand einen Treffer. Also meldete das Skript ein laufendes Softwareupdate, und wir warteten.

Es gab kein Update. softwareupdated ist ein Daemon, der auf jedem Mac dauerhaft läuft. Eine Teilstring-Suche findet ihn, ob gerade etwas passiert oder nicht. Der Besitzer der Maschine bemerkte es mit einer einfachen Frage: Es sollte gar kein Update laufen, was ist also das Problem? Die Prüfung hatte keine Antwort, weil sie nie eine hatte.

Die Lösung: Suchen Sie nach dem, was ein laufendes Update hinterlässt. Ein laufender Download oder anhaltende Festplattenaktivität ist ein Beleg. Ein Prozessname, der immer vorhanden ist, nicht.

2. Das Xcode, das in null Sekunden kopiert war

Wir klonen Xcode zwischen Maschinen, indem wir ein tar-Archiv über SSH streamen. Bei einem Lauf ging der Stream über einen Laptop, dem der Arbeitsspeicher ausging. Die sendende Seite starb. Das empfangende tar -xf - las einen leeren Stream, entpackte nichts und endete mit null. Das Skript gab XCODE_COPIED aus.

Bewegt hatten sich null Bytes. Der Exit-Code war ehrlich in Bezug auf den Auftrag an tar: alles entpacken, was ankommt. Es kam nichts an.

# 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. Das Recht, das als vergeben gemeldet wurde

macOS schützt die Bildschirmaufnahme mit einem Recht, das nur ein Mensch oder ein MDM-Profil vergeben kann. Apples Werkzeug kickstart gibt eine klare Warnung aus, wenn das Recht fehlt. Unsere Prüfung suchte nach dieser Warnung. Sie fand keine und meldete das Recht als vergeben.

Hat das Werkzeug selbst gar keine Rechte, gibt es nichts aus. Keine Warnung, überhaupt nichts. Das Fehlen einer Warnung sah genau wie Erfolg aus. Die ganze Geschichte steht in der Mac, der Sie anmeldet und nichts zeigt. Die Lösung war, nicht mehr das Werkzeug nach seiner Meinung zu fragen. Stattdessen messen wir echte Pixel aus dem Framebuffer.

4. Der Desktop, der als tot gemeldet wurde

Um zu prüfen, ob ein Benutzer in der GUI angemeldet ist, haben wir nachgesehen, wem /dev/console gehört. Auf einer neuen Maschine stand dort root. Wir schlossen daraus, dass niemand angemeldet war. Dann prüften wir die Maschine eines Kunden, auf der seit zwei Tagen ein Benutzer angemeldet war. Auch dort stand root.

Etwa zehn Minuten lang wurde der Desktop eines zahlenden Kunden als ausgefallen gemeldet. Er war in Ordnung. Der Besitzer des Geräteknotens bedeutet einfach nicht, was wir angenommen hatten. who listet eine console-Zeile nur, wenn eine Sitzung existiert. Genau das meldet unsere Telemetrie jetzt.

5. Der Fehler, der eine Konstante war

Eine Maschine mit einer brandneuen macOS-Hauptversion meldete sich nicht automatisch an. Apples sysadminctl -autologin set lieferte SACSetAutoLoginPassword error:22. Neues OS, neuer Fehler, naheliegender Schluss: Die neue Version hatte die geskriptete automatische Anmeldung kaputtgemacht.

Dann führten wir denselben Befehl auf einer gesunden Maschine eine Hauptversion darunter aus. Dort funktionierte die automatische Anmeldung seit Wochen. Derselbe Fehler. Der Befehl scheitert auf funktionierenden und kaputten Systemen gleich. Über keines von beiden sagte er also etwas aus. Die wahre Ursache war ein vorübergehender Zustand beim ersten Start. Die selbstsichere Diagnose war falsch, und die Gegenprobe widerlegte sie in unter einer Minute.

Die Regel und zwei Folgerungen

Alle fünf fallen schon bei der ersten Frage durch. Vier Tage gingen für ihre Verfolgung drauf. Keines der Systeme dahinter war so kaputt, wie die Prüfungen behaupteten.

Was sich geändert hat

Die Bildschirmprüfung misst den Framebuffer und zählt Farben. Die Sitzungsprüfung nutzt who und läuft in der Telemetrie mit. Eine Maschine am Anmeldefenster löst also einen Alarm aus, statt gesund auszusehen. Kopien werden über ihre Größe geprüft und indem das kopierte Programm ausgeführt wird. Und kein Fehler bekommt eine Ursache, bevor dieselbe Prüfung auf etwas lief, das bekanntermaßen funktioniert. Nichts davon ist raffiniert. Es ist immer dieselbe Frage, gestellt bevor die Prüfung geschrieben wird, nicht erst nachdem sie gelogen hat.