El Mac se congela tras despertar con la VPN: qué registrar
Un bloqueo tras despertar puede ser todo el escritorio, el cliente o una aplicación que espera. Decide qué falló y luego captura el informe que encaja con ese síntoma.
Los informes de un Mac congelado tras despertar suelen fundir tres fallos en una sola queja. El puntero puede seguir moviéndose mientras el cliente de VPN ignora los clics, el cliente puede funcionar mientras una sesión remota caduca, o todo el escritorio puede dejar de aceptar entrada. Cada uno de esos casos necesita pruebas distintas, y el primer minuto tras el bloqueo decide cuál tienes delante. Una suposición equivocada envía cada paso posterior en la dirección equivocada.
Qué dejó de responder y qué solo dejó de esperar
Empieza por las pruebas más baratas: mueve el puntero y escribe en un campo de texto local, abre la vista de estado del propio cliente y lee el estado que informa, y luego inicia una operación nueva en la aplicación privada en lugar de reanudar la sesión que ya estaba abierta. Anota las tres respuestas antes de tocar cualquier otra cosa, porque el orden de lo que falló es el primer detalle que la gente olvida.
Cada resultado apunta a un sitio distinto. Una sola sesión atascada pone la evidencia al otro lado del túnel, y el Mac solo es un espectador. Un cliente que ignora los clics mientras el escritorio sigue funcionando reduce la búsqueda a ese proceso y a su registro. Una máquina que ignora el puntero elimina la opción de ejecutar cualquier cosa, porque cada orden de inspección necesita un shell que responda.
Mantén los tres casos separados incluso cuando el usuario los describe en una sola frase. El informe que presentas debe decir qué prueba falló primero y cuáles seguían pasando, no que la máquina se congeló. Esa distinción es lo que permite a un ingeniero de soporte decidir si mirar la red, el cliente o el hardware.
Una cronología que aún podrás defender mañana
El reloj es la parte del registro que no se puede reconstruir después. Anota cuándo se abrió la tapa o despertó la máquina, cuándo ocurrió la primera acción fallida, y si esos dos momentos estaban separados por segundos o por minutos. Después escribe si el Mac durmió de verdad o solo bloqueó la pantalla, porque son estados distintos con rutas de despertar distintas. El registro de sueño es la única parte de esa cronología que puedes comprobar después.
pmset -g log | grep -i -E 'wake|sleep'
log show --last 15m --predicate 'process == "<client-process>"' --style compactEl primer comando convierte un recuerdo vago en una marca de tiempo que puedes escribir en el segundo. Limita la consulta del registro al proceso del cliente y a una ventana corta, y obtendrás una página de salida en lugar de un día entero. Copia el identificador del modelo, la compilación del cliente y la red en la que estabas en la misma nota mientras la pantalla sigue delante de ti; un informe montado a la mañana siguiente pierde el orden que lo hacía legible.
Elige la captura que encaja con el síntoma
Apple documenta tres capturas en la guía de diagnóstico de Activity Monitor, y responden a preguntas distintas. Sample Process observa un proceso seleccionado durante tres segundos, spindump apunta a una aplicación que ha dejado de responder y está a punto de ser forzada a cerrar, y System Diagnostics recoge los registros del sistema en un paquete.
Elige por lo que observaste, no por costumbre. Un cliente que funciona pero se comporta mal recibe un sample, tomado con sample <pid> 3 -file ~/Desktop/sample.txt o desde el menú del engranaje. Una aplicación que gira para siempre y hay que matar recibe el elemento Spindump de ese mismo menú. Un problema que abarca el cliente y el sistema recibe sudo sysdiagnose -f ~/Desktop. Toma el sample antes de forzar el cierre cuando puedas, porque la terminación destruye exactamente el estado que querías inspeccionar, y pon al archivo el nombre del evento y la hora en lugar de tu suposición sobre la causa.
Trata cada paquete como sensible. Estos informes llevan nombres de cuenta, nombres de host, rutas y detalles de red, así que envíalos por el canal de soporte que usa tu organización en lugar de adjuntarlos a un hilo público. Si hay que recortar un informe, recorta una copia y deja el original intacto.
Cuando el propio puntero no se mueve
Una interfaz muerta cambia el orden de las operaciones. No puedes muestrear un proceso ni ejecutar una consulta desde un shell que no responde, así que el primer objetivo es la recuperación y el segundo es un registro. Un reinicio forzado es a veces la única salida, y también es el momento en que desaparecen los detalles más útiles. Anota la hora, las ventanas que estaban abiertas y si el menú de red mostraba conexión antes de reiniciar; esas observaciones sobreviven al reinicio aunque el estado del proceso no lo haga.
Cuando la máquina vuelve, resiste la conclusión de que el reinicio encontró al culpable. Restauró el servicio y no nombró nada. Solo una repetición con un cambio controlado puede señalar un componente.
Si el bloqueo vuelve, cambia una condición por intento: la red, la versión del cliente o el modo de suspensión. Guarda primero el trabajo remoto y evita repetir suspensiones forzadas en una máquina de producción, porque los ciclos duros repetidos arriesgan pérdida de datos y a menudo producen un fallo distinto del que persigues. Anota cada intento con sus condiciones para que el siguiente sea comparable y no anecdótico.
Entrega un evento, no un estado de ánimo
La entrega que consigue acción nombra cuatro cosas: qué dejó de responder, cuándo ocurrió, cómo era la red en ese momento y qué captura cubre la ventana. Añade la versión del cliente y la compilación de macOS, y luego para. Tanto el equipo de plataforma como el proveedor del cliente pueden actuar sobre esa frase, y ninguno puede actuar sobre una descripción de frustración. Mantén el registro en un solo sitio y añade a él en lugar de volver a contar la historia cada vez; si una actualización cambió el comportamiento, indica cuál, porque eso también es evidencia.
Un buen registro también dice qué has descartado ya. Si una aplicación local respondía durante el bloqueo, dilo; si el registro de sueño muestra un despertar real y no un bloqueo, dilo también. La siguiente persona no debería tener que repetir pruebas que ya has hecho.
Antes de cerrar el tique, comprueba tres cosas: la marca de tiempo viene del registro de sueño y no de la memoria, la captura encaja con el síntoma que viste de verdad, y el paquete está en la ubicación aprobada. Si falta cualquiera de las tres, el informe no está listo para enviarse.