Verificações que não podem falhar: cinco falsos positivos em uma semana de automação de Macs

Uma regra teria nos poupado quase uma semana. Antes de confiar em uma verificação, pergunte o que ela mostra quando a coisa está quebrada. Se a resposta for "a mesma coisa", você não tem uma verificação. Tem um enfeite que diz OK.

Aqui estão cinco que encontramos em uma semana, todas no macOS, todas em automações que rodavam sem reclamar havia meses. Cada uma deu uma resposta errada com toda a confiança, e cada uma mandou uma pessoa consertar algo que não estava quebrado.

1. A atualização que não estava rodando

Uma máquina parecia lenta para voltar depois de reiniciar. Um pgrep -f softwareupdate rápido encontrou um resultado, então o script informou que havia uma atualização de software em andamento, e esperamos.

Não havia atualização nenhuma. O softwareupdated é um daemon residente em todo Mac, e uma busca por parte do nome encontra ele, esteja acontecendo algo ou não. O dono da máquina percebeu com uma pergunta simples: não deveria haver atualização nenhuma, então qual é o problema? A verificação não tinha resposta, porque nunca teve.

A solução é procurar o que uma atualização em andamento deixa para trás. Um download em curso ou atividade de disco constante é prova. Um nome de processo que está sempre presente, não.

2. O Xcode que foi copiado em zero segundos

Clonamos o Xcode entre máquinas mandando um arquivo tar por SSH. Uma das execuções passou por um laptop que ficou sem memória. O lado que enviava morreu, o tar -xf - do outro lado leu um fluxo vazio, não extraiu nada e saiu com zero. O script mostrou XCODE_COPIED.

Zero bytes tinham sido transferidos. O código de saída era honesto sobre o que o tar tinha recebido como tarefa, que era extrair o que chegasse. Nada chegou.

# 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. A permissão que aparecia como concedida

O macOS protege a gravação de tela com um privilégio que só uma pessoa ou um perfil MDM pode conceder. A ferramenta kickstart da Apple mostra um aviso claro quando o privilégio está faltando. Nosso teste procurava esse aviso e, sem encontrar, informava que o privilégio estava concedido.

Quando a ferramenta não tem privilégio nenhum, ela não mostra nada. Nem aviso, nem coisa alguma. A falta de aviso parecia exatamente um sucesso. A história completa está em o Mac que deixa você entrar e não mostra nada. A solução foi parar de pedir a opinião da ferramenta e medir pixels reais do framebuffer.

4. A área de trabalho que aparecia como morta

Para confirmar que um usuário estava logado na interface gráfica, verificávamos quem era o dono de /dev/console. Em uma máquina nova dizia root, então concluímos que ninguém estava logado. Depois verificamos a máquina de um cliente, que tinha um usuário logado havia dois dias. Também dizia root.

Por uns dez minutos, a área de trabalho de um cliente pagante apareceu como fora do ar. Estava tudo bem. O dono do device node simplesmente não significa o que achávamos. O who só mostra uma linha console quando existe uma sessão, e é isso que a nossa telemetria informa agora.

5. O erro que era uma constante

Uma máquina com uma versão principal novinha do macOS não fazia login automático. O sysadminctl -autologin set da Apple retornava SACSetAutoLoginPassword error:22. Sistema novo, erro novo, conclusão óbvia: a nova versão tinha quebrado o login automático por script.

Aí rodamos o mesmo comando em uma máquina saudável, uma versão principal atrás, onde o login automático funcionava havia semanas. Mesmo erro. O comando falha do mesmo jeito em sistemas que funcionam e em sistemas quebrados, então não dizia nada sobre nenhum dos dois. A causa real era uma condição passageira da primeira inicialização. O diagnóstico confiante estava errado, e o teste de controle derrubou ele em menos de um minuto.

A regra, e duas consequências

Todas as cinco reprovam na primeira pergunta. Foram quatro dias correndo atrás delas. Nenhum dos sistemas por trás estava quebrado do jeito que as verificações diziam.

O que mudou

A verificação de tela mede o framebuffer e conta cores. A verificação de sessão usa o who e vai na telemetria, então uma máquina parada na tela de login gera um alerta em vez de parecer saudável. Cópias são conferidas pelo tamanho e rodando o binário copiado. E nenhuma falha ganha uma causa raiz antes de a mesma verificação rodar em algo que sabidamente funciona. Nada disso é genial. Tudo é a mesma pergunta, feita antes de escrever a verificação, e não depois de ela ter mentido.