Comprobaciones que no pueden fallar: cinco falsos positivos en una semana de automatizar Mac
Una regla nos habría ahorrado casi una semana. Antes de fiarte de una comprobación, pregúntate qué muestra cuando la cosa está rota. Si la respuesta es "lo mismo", no tienes una comprobación. Tienes un adorno que dice OK.
Aquí van cinco que encontramos en una semana, todas en macOS, todas en automatizaciones que llevaban meses funcionando sin quejas. Cada una dio una respuesta errónea con total seguridad. Y cada una mandó a una persona a arreglar algo que no estaba roto.
| Comprobación | Muestra si funciona | Muestra si falla | Veredicto |
|---|---|---|---|
| pgrep -f softwareupdate | encuentra el daemon inactivo | encuentra el daemon inactivo | inútil |
| tar -xf - ; echo COPIED | COPIED | COPIED (0 bytes) | inútil |
| prueba de privilegios con kickstart | no muestra ningún aviso | no muestra nada en absoluto | inútil |
| stat -f %Su /dev/console | root | root | inútil |
| sysadminctl -autologin set | error:22 | error:22 | inútil |
1. La actualización que no se estaba ejecutando
Una máquina parecía tardar en volver tras un reinicio. Un rápido pgrep -f softwareupdate encontró una coincidencia, así que el script informó de que había una actualización en curso y esperamos.
No había ninguna actualización. softwareupdated es un daemon residente en todos los Mac, y una búsqueda por subcadena lo encuentra pase algo o no. El dueño de la máquina lo detectó con una pregunta sencilla: no debería haber ninguna actualización, así que ¿cuál es el problema? La comprobación no tenía respuesta, porque nunca la tuvo.
La solución es buscar lo que deja una actualización en marcha. Una descarga en curso o una actividad de disco sostenida son pruebas. Un nombre de proceso que siempre está presente no lo es.
2. El Xcode que se copió en cero segundos
Clonamos Xcode entre máquinas enviando un archivo tar por SSH. Una ejecución lo pasó por un portátil que se quedó sin memoria. El lado emisor murió. El tar -xf - receptor leyó un stream vacío, no extrajo nada y salió con cero. El script mostró XCODE_COPIED.
No se había movido ni un byte. El código de salida decía la verdad sobre lo que se le había pedido a tar, que era extraer lo que llegara. No llegó nada.
# 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. El permiso que figuraba como concedido
macOS protege la grabación de pantalla tras un privilegio que solo puede conceder una persona o un perfil MDM. La herramienta kickstart de Apple muestra un aviso claro cuando falta el privilegio. Nuestra prueba buscaba ese aviso y, al no encontrarlo, daba el privilegio por concedido.
Cuando la herramienta no tiene ningún privilegio, no muestra nada. Ni aviso ni nada. La ausencia de aviso parecía exactamente un éxito. La historia completa está en el Mac que te deja entrar y no te enseña nada. La solución fue dejar de preguntar la opinión de la herramienta y muestrear píxeles reales del framebuffer.
4. El escritorio que figuraba como caído
Para confirmar que un usuario había iniciado sesión en la interfaz gráfica, mirábamos quién era el dueño de /dev/console. En una máquina nueva decía root, así que concluimos que no había nadie conectado. Luego miramos la máquina de un cliente, con un usuario conectado desde hacía dos días. También decía root.
Durante unos diez minutos, el escritorio de un cliente de pago figuró como caído. Estaba bien. El dueño del nodo de dispositivo sencillamente no significa lo que suponíamos. who muestra una línea console solo cuando existe una sesión, y eso es lo que informa ahora nuestra telemetría.
5. El error que era una constante
Una máquina con una versión mayor de macOS recién salida no hacía el inicio de sesión automático. El sysadminctl -autologin set de Apple devolvía SACSetAutoLoginPassword error:22. Sistema nuevo, error nuevo, conclusión obvia: la nueva versión había roto el inicio de sesión automático por script.
Después ejecutamos el mismo comando en una máquina sana con la versión mayor anterior, donde el inicio automático llevaba semanas funcionando. Mismo error. El comando falla igual en sistemas que funcionan y en sistemas rotos, así que no aportaba información sobre ninguno. La causa real resultó ser una condición pasajera del primer arranque. El diagnóstico tan seguro era erróneo, y la prueba de control lo desmintió en menos de un minuto.
La regla, y dos corolarios
Las cinco suspenden la primera pregunta. Perdimos cuatro días persiguiéndolas. Ninguno de los sistemas de fondo estaba roto de la forma en que decían las comprobaciones.
Qué cambió
La comprobación de pantalla muestrea el framebuffer y cuenta colores. La de sesión usa who y va en la telemetría, así que una máquina en la ventana de inicio de sesión lanza una alerta en lugar de parecer sana. Las copias se verifican por tamaño y ejecutando el binario copiado. Y ningún fallo recibe una causa raíz hasta que la misma comprobación se ha ejecutado en algo que sabemos que funciona. Nada de eso es ingenioso. Todo es la misma pregunta, hecha antes de escribir la comprobación y no después de que haya mentido.
Haz tus propias cuentas con la calculadora o alquila un runner.