¿Cómo verificar qué impide que MBP se apague o reinicie correctamente y solucionarlo? [Ahora con entradas de registro]

Y, con suerte, la edición final: después de actualizar a Mountain Lion, el problema parece solucionado, con suerte de forma permanente.

Edición final: el problema no ocurre todo el tiempo, a veces tengo que esperar varios días para que ocurra. Por lo tanto, es difícil probar en diferentes condiciones (es decir, en modo seguro o con algún software deshabilitado) y he decidido que no vale la pena pasar días probando diferentes condiciones para solucionar esto. Las sugerencias de Graham Perrin fueron las más útiles para encontrar información específica sobre problemas de reinicio/reinicio, que no se encuentra en los registros de propósito general.

Algunas entradas de registro están en Editar en la parte inferior:

MacBook Pro de 15 pulgadas de mediados de 2010, con OS X 10.7.4. A veces, cuando intento reiniciar o apagar la máquina, no funciona: la pantalla se vuelve gris, se muestra la rueda giratoria, pero la máquina no se apaga, así que después de varios minutos tengo que apagar la máquina presionando el botón de encendido. botón.

No sucede siempre, y no puedo relacionar ningún software utilizado durante la sesión con el problema. De hecho, al probar esto, a veces esto sucede cuando intento apagar la máquina inmediatamente después de encenderla.

¿Cómo verificar qué impide el apagado/reinicio correcto? Supongo que tengo que buscar en algunos archivos de registro, pero no estoy seguro de cuáles y qué buscar.

Editar: se agregó la configuración detallada de inicio/apagado en el nvram según lo sugerido por Graham Perrin y, finalmente, la máquina se atascó al reiniciar. Vi algunas entradas detalladas en la pantalla y después de reiniciar las encontré en /var/log/launchd-shutdown.log. Parece que WindowServer puede tener algo que ver con eso. A continuación se muestra el final de ese archivo de registro con las primeras 3 columnas eliminadas (la primera tenía algunos números enteros crecientes, la segunda tenía entradas de "1" y la tercera, "com.apple.launchd"):

234 com.apple.WindowServer   Dispatching kevent callback.
234 com.apple.WindowServer   Job has not died after being killed 2 seconds ago. Simulating exit.
234 com.apple.WindowServer   Dispatching kevent callback.
234 com.apple.WindowServer   EVFILT_PROC event for job.
1 com.apple.launchd         KEVENT[0]: udata = 0x107827a90 data = 0x0 ident = 234 filter = EVFILT_PROC flags= 0x0 fflags = NOTE_EXIT
234 com.apple.WindowServer   Reaping
234 com.apple.WindowServer   Simulated exit: <rdar://problem/9359725>
234 com.apple.WindowServer   Exited 22.016701 seconds after the first signal was sent
0 com.apple.WindowServer     Exited while shutdown in progress. Processes remaining: 0/0
0 com.apple.WindowServer   Job was last to exit during shutdown of: System.
0 com.apple.WindowServer    Total rusage: utime 0.000000 stime 0.000000 maxrss 0 ixrss 0 idrss 0 isrss 0 minflt 0 majflt 0 nswap 0 inblock 0 oublock 0 msgsnd 0 msgrcv 0 nsignals 0 nvcsw 0 nivcsw 0
0 com.apple.WindowServer  Closing receive right for com.apple.windowserver.active
0 com.apple.WindowServer  Mach service deleted: com.apple.windowserver.active
0 com.apple.WindowServer  Closing receive right for com.apple.windowserver
0 com.apple.WindowServer   Mach service deleted: com.apple.windowserver
0 com.apple.WindowServer    Removed
1 com.apple.launchd      System: No submanagers left.
1 com.apple.launchd    System: Removing.
1 com.apple.launchd   System: Removing job manager.
1 com.apple.launchd    System: Userspace shutdown finished at: Wed Aug  1 08:53:12 2012
1 com.apple.launchd   System: Userspace shutdown took approximately 22 seconds.
1 com.apple.launchd   VM statistics (now - orig): Free: 28472 Active: -21833 Inactive: -1038 Reactivations: 0 PageIns: 25 PageOuts: 0 Faults: 1654 COW-Faults: 335 Purgeable: -849 Purges: 0
1 com.apple.launchd   System: Stray process at shutdown: PID 234 PPID 1 PGID 234 WindowServer
1 com.apple.launchd       System: About to call: reboot(RB_HALT).
Conecte cualquier disco de uso normal, realice cualquier conexión de servidor de archivos de uso normal y, a continuación, ejecute el mountcomando. Incluir el resultado en su pregunta podría ayudar a reducir las cosas.
No hay discos que se usen normalmente o conexiones de servidor de archivos, estoy conectando unidades USB un par de veces al mes, pero no tengo ninguna para probar en este momento. Ejecuté 'mount' sin ningún disco conectado, pero no hay nada sospechoso.
Por favor, ¿qué versión de Little Snitch? ¿El problema es reproducible con arranque seguro o sin Little Snitch?
El último LS estable (2.5.3), no la vista previa de la versión 3. Pero esto también sucedía con las versiones 1-2 anteriores. No puedo probar esto razonablemente sin LS o en modo seguro, ya que esto no sucede todo el tiempo, a veces toma días para que suceda y no puedo ejecutar la máquina así por largos períodos de tiempo. Supongo que viviría con esto por ahora, y actualizaré a Mountain Lion y veré qué sucede. Pero sus sugerencias fueron muy útiles y específicas, por lo que obtiene la recompensa.
¡Gracias! Según su plan para actualizar el sistema operativo, agregué una sección a mi respuesta. La respuesta más corta ahora es que, en comparación con 10.7.4, 10.8 debería ser (a) menos probable que requiera fuerza; y (b) más fácil de diagnosticar en caso de fuerza.

Respuestas (8)

Complementando otras respuestas…

Observe el modo detallado durante el reinicio o el apagado

Mac OS X: Cómo iniciar en modo monousuario o detallado

– si comienza en modo detallado, reiniciar o apagar será igualmente detallado.

Sugerencia: si las cosas en modo detallado parecen no progresar más allá de cierto punto, espere unos cinco minutos antes:

  • forzar un reinicio (Comando-Control-encendido); o
  • forzar un apagado (presione y mantenga presionada la tecla de encendido).

Si un reinicio forzado no tiene éxito, esa podría ser otra pista sobre la causa del problema (s).

Una pregunta relacionada, aunque no orientada a problemas: ¿alguien puede interpretar mensajes detallados de apagado?

El caso orientado a problemas aquí debería ser más fácil de resolver para lupincho. Menos hojas de té.

Para comenzar en modo detallado sin teclear Comando-V

Una preferencia se puede almacenar en NVRAM. Ingrese el siguiente comando en la Terminal y prepárese para ingresar su contraseña de administrador:

sudo nvram boot-args="-v"

El próximo inicio del sistema será detallado.

diagnóstico del sistema

Antes de cada reinicio o apagado, en Terminal:

sudo sysdiagnose

Lleva mucho tiempo, pero no necesita investigar los resultados de todas las ejecuciones. Preste atención sólo si surge un problema.

Para un caso como el de lupincho:

  • la ejecución sysdiagnosepuede revelar un problema antes de reiniciar o apagar
  • el resultado final de sysdiagnose puede ser de interés después de un reinicio o apagado forzado .

Más específicamente: si una serie de sysdiagnosefallas en progresar más allá de cierto punto, conocer ese punto puede ayudar a tener una idea del problema subyacente.

Durante la ejecución, puede usar la siguiente combinación de teclas, repetidamente, para ver si las cosas están progresando:

  • Control-T

Para la allmemoryparte de la sysdiagnoserutina, la estimación de dos minutos de Apple puede ser muy imprecisa. Ser paciente.

Si sospecha que sysdiagnoseno progresa más allá de cierto punto, entonces clave:

  • Control-C

Si el uso repetido de Control-C falla sysdiagnose, entonces (según mi experiencia con Mountain Lion) es casi seguro que un intento de reiniciar o apagar el sistema operativo fallará.

Monitoreo de apagado

En Finder, vaya a:

/private/var/log/shutdown_monitor.log

Este archivo suele estar vacío, pero puede contener elementos de interés después de un apagado problemático. (Tengo poca experiencia en esta área.)

Si el único proceso extraviado al apagar es WindowServer

No es inusual tener procesos perdidos al apagar. Un perro callejero puede ser problemático solo si no se lo mata.

Si sospecha que WindowServer no está desactivado y que este error en particular contribuye a la falla de apagado: pregúntese si algún software de terceros hace un uso no estándar del proceso de WindowServer.

Vista rápida de una vista de GrabFS de WindowServer en Mountain Lion, con dos pantallas:

ingrese la descripción de la imagen aquí

Si Lion es similar, mi intuición es que la causa de las fallas de apagado se encuentra más allá de WindowServer.

Conjeturas, basadas en los resultados de launchctl

Mientras la máquina funciona normalmente, ¿qué respuesta al siguiente comando?

sudo launchctl list | grep  --invert-match com.apple

Me pregunto si algún software que no sea de Apple contribuye al problema. ¿Software antivirus, antimalware?

Después de una actualización de Lion a Mountain Lion

Aspirar a:

/private/var/log/com.apple.launchd/launchd-shutdown.system.log

Parece que el valor predeterminado es un registro por apagado, con un máximo de dos, por lo que también hay:

/private/var/log/com.apple.launchd/launchd-shutdown.system.log.1

Después de cualquier reinicio forzado o apagado forzado, puede optar por reservar una copia del más reciente de los dos. Si se requiere fuerza en más de una ocasión, puede comparar archivos para ver si surge un patrón.

En general

No descarte la posibilidad de un problema con el software de terceros, incluso con la calidad del lanzamiento. Little Snitch puede estar bien escrito y ser ampliamente respetado, pero:

  • cuando problemas como el de esta pregunta se vuelven extensos o demasiado desconcertantes, cualquier extensión del kernel que no sea de Apple merece atención.

Probé la compilación 12A269 de OS X 10.8 durante aproximadamente dos semanas antes de su lanzamiento, con especial atención a los comportamientos de apagado en situaciones difíciles . Si bien no he visto ningún video de WWDC 2012, tengo la sensación de que Apple ha trabajado muy duro para evitar la necesidad de usar la fuerza en todas las situaciones, excepto en las más difíciles.

Sobre la base de la respuesta de David DelMonte

Al menos en Mountain Lion, veo la carga de Little Snitch 3.0 Preview 2 (3857) muy temprano, antes de que comience el registro de apagado . Si las cosas relacionadas con este KEXT se retrasan de manera similar alrededor del tiempo de apagado , entonces tal vez un problema no sea evidente en los archivos de registro habituales en el disco.

Si alguna vez descubre la causa del problema, ya sea con Lion o Mountain Lion, estaré encantado de saberlo.

Mientras tanto, con un gran agradecimiento por la generosidad, un pensamiento final:

kextstat -l | grep --invert-match com.apple
Gracias, habilité el modo detallado con el comando nvram. Sin embargo, incluso después de reiniciar, no hay shutdown_monitor.log. Hay archivos launchd-shutdown.log y launchd-shutdown.log.1 (parece que solo se mantienen el actual y 1 anterior, a diferencia de otros registros), pero estos estaban allí antes y los miré anteriormente. Verificaré los mensajes de apagado del modo detallado, espero poder ver dónde se atasca el apagado/reinicio.
Si se repite un problema, tome una foto o dos de la verbosidad. No se preocupe demasiado por el enfoque, etc., reconoceré los puntos clave incluso con algo de desenfoque. Tengo una corazonada sobre lo que está mal en su caso, la sysdiagnoseparte nueva de esta respuesta puede ser más relevante.
Nota al margen: aquí con Mountain Lion tengo /private/var/log/kernel-shutdown.log(con información que me es útil) pero no /private/var/log/launchd-shutdown.log.
Gracias por la sugerencia 'sysdiagnose', solo ejecútelo, salió bien, lo intentaré nuevamente. Como dijiste, lleva algo de tiempo, de lo contrario, podría ponerlo en gancho de cierre de sesión para que se ejecute cada vez.
La automatización es tentadora, pero debo abstenerme de hacer sysdiagnoseun elemento de cierre de sesión. En un caso extremo, la automatización podría empeorar una situación difícil.
Sin software antivirus o antimalware; solo pequeño soplón. El resultado de ese comando launchctl muestra el software de Apple - 0 com.microsoft.office.licensing.helper; - 0 com.adobe.fpsaud; 68 - at.obdev.littlesnitchd

Vaya a Aplicaciones -> Utilidades y abra Consola

Eche un vistazo al archivo system.log, es posible que pueda encontrar algo allí.

No veo nada extraño allí.
Buena respuesta de Revolver. +1. ¿Podría copiar y pegar en su pregunta las entradas de system.log que ve después de solicitar un apagado, y tal vez unos minutos antes? Péguelas en su pregunta original.
Revisé system.log varias veces en el pasado y no encontré nada inusual en comparación con los apagados correctos. Esperará la próxima vez que esto suceda y verificará los registros nuevamente. Debería haber aclarado que estoy al tanto de los registros de propósito general, lo actualizaré en mi publicación original.

pmset -g assertionsobtiene un resumen de afirmaciones de poder:

$ pmset -g assertions
Assertion status system-wide:
   PreventUserIdleDisplaySleep             0
   CPUBoundAssertion                       0
   DisableInflow                           0
   ChargeInhibit                           0
   PreventSystemSleep                      0
   PreventUserIdleSystemSleep              1
   ExternalMedia                           1
   DisableLowPowerBatteryWarnings          0
   EnableIdleSleep                         1
   NoRealPowerSources_debug                0
   UserIsActive                            0
   ApplePushServiceTask                    0

Listed by owning process:
  pid 153: [0x00000099012c023b] PreventUserIdleSystemSleep named: "com.apple.audio.'AppleUSBAudioEngine:Apple Inc.:Display Audio:15261930:2,1'.noidlesleep" 
  pid 19: [0x00000013012c0235] ExternalMedia named: "com.apple.powermanagement.externalmediamounted"

Puede ver la ruta de un proceso con ps up $pid:

$ ps up 153
USER          PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
_coreaudiod   153   0.0  0.2  2475000   6740   ??  Ss   Fri05PM  12:17.71 /usr/sbin/coreaudiod
Lo ejecuto y no muestra nada. El problema es que después de iniciar el apagado/reinicio no puedo ejecutar ningún comando. Además, el problema no aparece siempre, por lo que tendría que verificar esto con frecuencia o escribir un script para guardar la información en un archivo para que, después de un apagado/reinicio problemático, pueda volver a ese archivo y ver si aparece algo. . Pero parece un buen punto de partida, ¡muchas gracias!

Solía ​​tener este problema y encontré una solución que funcionó para mí. Aunque no estoy respondiendo directamente a su pregunta (cómo verificar qué está causando el problema), es una solución que podría valer la pena intentar:

  1. Vaya a "Macintosh HD > Biblioteca"
  2. Eliminar la carpeta llamada "Java"
  3. Papelera vacía
  4. Apagar
  5. Una vez que ejecute cualquier cosa relacionada con Java, se le pedirá que reinstale Java, hágalo.

Después de eso, el tiempo de apagado debería mejorar. Nota: Sigo teniendo apagados lentos cuando apago inmediatamente después de que se inicia el sistema, así que después de seguir los pasos y desea probar, espere unos minutos después de que el sistema se inicie antes de apagar.

Eso es interesante; hizo eso, vamos a ver qué pasa. El problema es que no siempre sucede, por lo que la única forma de verificar es esperar varios días y si no vuelve a suceder, esto puede significar que está solucionado.
No funcionó, solo tuve un problema al apagar la máquina.
  1. ¿Tienes algún equipo periférico conectado (USB, FW, etc)?

Si es así, sería interesante desconectar todo y ver si existe el problema.

  1. ¿Has probado a reparar los permisos y comprobar la integridad de los archivos?

Espero que esto ayude.

Reparé permisos. Sin periféricos, ni siquiera un cable ethernet. Agregará esa información a la pregunta.
Periféricos: siempre es bueno considerarlos cuando (como en la pregunta de lupincho) hay un indicio de un problema con las E/S. Permisos: en mi humilde opinión, es probable que nunca evite el cierre del sistema operativo. Desintegración: posible, pero para mí la pregunta en su forma actual huele más a un problema con el software. (Nota al margen, sobre la integridad: ¿Qué software gratuito o de código abierto puedo usar con el hardware de Mac para verificar la integridad de cada bloque de un disco donde se usa Core Storage? Hay demasiada cháchara tecnológica en este momento, eventualmente debería condensarse en algo más. más simple.)

Algunas ideas más:

  1. Crea otra cuenta de usuario. Inicie sesión solo como esta cuenta de prueba. Si no tiene el problema, es probable que sea algo en su software de usuario. Si tiene el problema, es posible que sea de hardware.

  2. Intente recrear el problema simplemente usando la energía de la batería.

  3. Siga los pasos para el controlador de administración del sistema de Apple:

Restablecimiento del controlador de administración del sistema (SMC) Restablecimiento del SMC en portátiles Mac con una batería que se puede quitar

Apaga el ordenador. Desconecte el adaptador de corriente MagSafe de la computadora, si está conectado. Retire la batería. Mantenga presionado el botón de encendido durante 5 segundos. Suelte el botón de encendido. Vuelva a conectar la batería y el adaptador de corriente MagSafe. Presione el botón de encendido para encender la computadora.

Voté principalmente por su idea (1). Para la idea (2), con los síntomas tal como se describen actualmente, personalmente no sospecharía ninguna diferencia solo con la energía de la batería. Sin embargo, problemas como el de lupincho son sorprendentemente difíciles de diagnosticar sin un acceso directo… así que no es una mala idea. Idea (3), los problemas resueltos por un reinicio son (para mí) extremadamente raros... pero, de nuevo, no es una mala idea: rápido y simple de realizar, así que esto también gana mi voto.

No me di cuenta de que tenías a Little Snitch corriendo. Acabo de resolver un problema similar para un amigo, eliminando LS. Te sugiero que pruebes eso. Para eliminar correctamente, descargue el instalador de LS nuevamente. Ejecute el instalador, pero seleccione desinstalar.

También tengo curiosidad por qué querrías usar esta aplicación.

Todavía no en la pregunta, Little Snitch se mencionó por primera vez en (más) comentarios a una respuesta.
Por favor: ¿la computadora de su amigo ejecutó Lion o Mountain Lion? ¿Qué versión de Little Snitch se desinstaló?
Ese fue León. No conozco la versión LS.. lo siento.
No hay pruebas de que LS esté causando eso y, desafortunadamente, debido a que el problema no ocurre siempre, probar esto con LS eliminado llevaría varios días durante los cuales no puedo perder LS. En cuanto a la razón para ejecutar LS: hay demasiados programas llamando a casa y es solo otro nivel de control para el tráfico saliente. Lo que eventualmente haría es actualizar a la versión 3 cuando se lance oficialmente.
Para fines de solución de problemas, Little Snitch se puede tratar de manera diferente a otros KEXT de terceros por al menos dos razones: (i) la rapidez de su carga y (ii) su ubicación en el dominio del Sistema en /System/Library/Extensions. Con crédito a David, agregué una sección a mi respuesta.

Mi novia simplemente había eliminado los directorios de los paralelos arrastrando y soltando el directorio en la papelera y vaciando la papelera. Sin embargo, encontré paralelos nuevamente dentro de la carpeta Biblioteca, y había un script de shell (archivo .sh) para desinstalarlo correctamente. Esto funcionó y resolvió nuestros problemas de arranque largo.

Menciono esto porque Parallels es una causa conocida de muchos arranques lentos y parece que no es tan fácil de desinstalar como indica su sitio web (simplemente arrastrando y soltando el directorio).

Senderos felices, espero que esto ayude a alguien.

¿Cómo verificar qué impide que MBP se apague o reinicie correctamente y solucionarlo? [Ahora con entradas de registro]
RespuestasAquíPolítica de privacidad1y, 0v