Проверки, которые не могут упасть: пять ложных срабатываний за неделю автоматизации Mac

Одно правило сэкономило бы нам большую часть недели. Прежде чем доверять проверке, спросите, что она выводит, когда всё сломано. Если ответ "то же самое", у вас нет проверки. У вас украшение с надписью OK.

Вот пять таких, которые мы нашли за одну неделю. Все на macOS, все в автоматизации, которая месяцами работала без нареканий. Каждая уверенно давала неверный ответ. И каждая отправляла человека чинить то, что не было сломано.

1. Обновление, которого не было

Машина, казалось, долго приходила в себя после перезагрузки. Быстрый pgrep -f softwareupdate нашёл совпадение. Скрипт сообщил, что идёт обновление ПО, и мы ждали.

Никакого обновления не было. softwareupdated это постоянно работающий демон на каждом Mac. Поиск по подстроке находит его, происходит что-то или нет. Владелец машины поймал это простым вопросом: никакого обновления идти не должно, так в чём проблема? У проверки не было ответа, потому что его не было никогда.

Исправление: искать то, что оставляет после себя идущее обновление. Загрузка в процессе или постоянная активность диска это доказательство. Имя процесса, которое есть всегда, нет.

2. Xcode, скопированный за ноль секунд

Мы клонируем Xcode между машинами, передавая tar-архив потоком по SSH. Один раз поток шёл через ноутбук, у которого кончилась память. Отправляющая сторона умерла. Принимающий tar -xf - прочитал пустой поток, ничего не распаковал и завершился с нулём. Скрипт вывел XCODE_COPIED.

Передано было ноль байт. Код выхода честно отражал то, что tar попросили сделать: распаковать всё, что придёт. Не пришло ничего.

# 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. Разрешение, которое числилось выданным

macOS закрывает запись экрана привилегией, которую может выдать только человек или профиль MDM. Инструмент Apple kickstart выводит понятное предупреждение, когда привилегии нет. Наша проверка искала это предупреждение и, не найдя его, сообщала, что привилегия выдана.

Когда у инструмента вообще нет прав, он ничего не выводит. Ни предупреждения, ни чего-либо ещё. Отсутствие предупреждения выглядело точно как успех. Вся история в посте Mac, который пускает вас внутрь и ничего не показывает. Исправление: перестать спрашивать мнение инструмента и вместо этого брать настоящие пиксели из фреймбуфера.

4. Рабочий стол, который числился мёртвым

Чтобы убедиться, что пользователь вошёл в графическую сессию, мы проверяли владельца /dev/console. На новой машине там был root, и мы решили, что никто не вошёл. Потом проверили машину клиента, где пользователь был в системе уже два дня. Там тоже был root.

Около десяти минут рабочий стол платящего клиента числился неработающим. С ним всё было в порядке. Владелец файла устройства просто означает не то, что мы думали. who показывает строку console, только когда сессия существует. Именно это теперь сообщает наша телеметрия.

5. Ошибка, которая была константой

Машина на совершенно новой мажорной версии macOS не входила в систему автоматически. sysadminctl -autologin set от Apple возвращал SACSetAutoLoginPassword error:22. Новая ОС, новая ошибка, очевидный вывод: новый релиз сломал автовход через скрипт.

Потом мы запустили ту же команду на исправной машине на одну мажорную версию старше, где автовход работал неделями. Та же ошибка. Команда падает одинаково и на рабочих, и на сломанных системах, поэтому ни о тех, ни о других ничего не сообщает. Настоящей причиной оказалось временное состояние при первой загрузке. Уверенный диагноз был неверным, и контрольный запуск опроверг его меньше чем за минуту.

Правило и два следствия

Все пять не проходят первый вопрос. На погоню за ними ушло четыре дня. Ни одна из систем не была сломана так, как утверждали проверки.

Что изменилось

Проверка экрана берёт пиксели из фреймбуфера и считает цвета. Проверка сессии использует who и входит в телеметрию. Поэтому машина на экране входа поднимает тревогу, а не выглядит здоровой. Копии проверяются по размеру и запуском скопированного бинарника. И ни один сбой не получает корневую причину, пока ту же проверку не запустят на заведомо рабочей системе. Ничего хитрого тут нет. Это всё тот же вопрос, только заданный до того, как проверка написана, а не после того, как она соврала.