← blog

Comprobaciones que no pueden fallar: cinco falsos positivos en una semana de automatizar Mac

20 de septiembre de 2026 · 8 min de lectura

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.

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.