¿Cómo verificar qué impide que MBP apague / reinicie correctamente y lo arregle? [Ahora con entradas de registro]

12

Y es de esperar una edición realmente 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 realizar pruebas bajo diferentes condiciones (es decir, modo seguro o con algún software deshabilitado) y he decidido que no vale la pena pasar días tratando 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 encuentran en los registros de uso general.

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

Mediados de 2010 15in MacBook Pro, con OS X 10.7.4. A veces, cuando intento reiniciar o apagar la máquina, no funciona: la pantalla se vuelve gris, la rueda giratoria muestra, 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 todo el tiempo, 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 iniciarla.

¿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).
lion  macos  shutdown  restart 
— lupincho
fuente
Conecte los discos que se usan normalmente, realice las conexiones del servidor de archivos que se usan normalmente, luego ejecute el mountcomando. Incluir el resultado en su pregunta podría ayudar a reducir las cosas.
— Graham Perrin
No hay discos normalmente utilizados o conexiones de servidor de archivos, estoy conectando unidades USB un par de veces al mes, pero no tengo ninguna que probar en este momento. Ejecuté 'mount' sin ningún disco conectado, pero no hay nada sospechoso.
— lupincho
Por favor, ¿qué versión de Little Snitch? ¿El problema es reproducible con un arranque seguro o sin Little Snitch?
— Graham Perrin el
El último LS estable (2.5.3), no la vista previa de la versión 3. Pero esto también estaba sucediendo con las versiones anteriores 1-2. No puedo probar esto razonablemente sin LS o en modo seguro, ya que esto no sucede todo el tiempo, a veces lleva días y no puedo ejecutar la máquina de esa manera 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.
— lupincho
¡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.
— Graham Perrin el

Respuestas:

6

Complementando otras respuestas ...

Observe el modo detallado durante el reinicio o apagado

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

- si comienza en modo detallado, reiniciar o apagar será similarmente detallado.

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

  • forzar un reinicio (Command-Control-power); o
  • forzar un apagado (mantenga presionada la tecla de encendido).

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

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

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

Para comenzar en modo detallado sin tener que presionar Command-V

Se puede almacenar una preferencia 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.

sysdiagnose

Antes de cada reinicio o apagado, en la Terminal: 

sudo sysdiagnose

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

Para un caso como el de lupincho:

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

Más específicamente: si una serie de sysdiagnoseno progresa 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 inexacta. Se paciente.

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

  • Control-C

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

Apagado de monitoreo

En Finder, ve a:

/private/var/log/shutdown_monitor.log

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

Si el único proceso perdido en el apagado es WindowServer

No es inusual tener procesos extraviados en el cierre. Un parásito puede ser problemático solo si no se mata.

Si sospecha que WindowServer no se elimina, y que este desvío en particular contribuye al fallo 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 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 los fallos de apagado está más allá de WindowServer.

Adivinanzas, basadas en los resultados de launchctl

Mientras la máquina está funcionando 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. ¿Antivirus, software 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, ni siquiera la calidad de lanzamiento. Little Snitch puede estar bien escrito y ser ampliamente respetado, pero:

  • Cuando problemas como el de esta pregunta se extienden o son demasiado desconcertantes, cualquier extensión que no sea del núcleo 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 cerrar comportamientos 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 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, me complacerá saberlo.

Mientras tanto, con muchas gracias por la recompensa, un pensamiento final: 

kextstat -l | grep --invert-match com.apple
— Graham Perrin
fuente
1
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 conservan los actuales y 1 anterior, a diferencia de otros registros), pero estos estaban allí antes y los miré anteriormente. Revisaré los mensajes detallados de apagado del modo, espero poder ver dónde se bloquea el apagado / reinicio.
— lupincho
Si el problema persiste, 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 el presentimiento de lo que está mal en su caso, la nueva sysdiagnoseparte de esta respuesta puede ser más relevante.
— Graham Perrin
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.
— Graham Perrin
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 el gancho de cierre de sesión para que se ejecute cada vez.
— lupincho
La automatización es tentadora, pero debería abstenerme de hacer sysdiagnoseun elemento de desconexión. En un caso extremo, la automatización podría empeorar una situación difícil.
— Graham Perrin
2

Vaya a Aplicaciones -> Utilidades y abra la Consola

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

— revólver
fuente
No veo nada extraño allí.
— lupincho
Buena respuesta de Revolver. +1. ¿Podría copiar y pegar en su pregunta, las entradas SYSTEM.LOG que se ve después de solicitar una parada - y tal vez un par de minutos antes .. pegarlos en su pregunta original ..
— David Delmonte
Revisé system.log varias veces en el pasado y no encontré nada inusual en comparación con los apagados apagados. Esperará la próxima vez que esto suceda y revisará los registros nuevamente. Debería haber aclarado que estoy al tanto de los registros de propósito general, actualizaré eso en mi publicación original.
— lupincho
2

pmset -g assertions obtiene un resumen de las 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
— Lri
fuente
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 siempre aparece, 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 eso parece un buen punto de partida, ¡muchas gracias!
— lupincho
1

Solía ​​tener este problema y encontré una solución que me funcionó. 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:

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

Después de eso, el tiempo de apagado debería mejorar. Nota: Todavía obtengo apagados lentos cuando apago inmediatamente después de que se inicia el sistema, por lo que después de seguir los pasos y realizar la prueba, espere unos minutos después de que se inicie el sistema antes de apagarse.

— bogdansrc
fuente
Eso es interesante; hizo eso, veamos qué pasa. El problema es que no sucede todo el tiempo, por lo que la única forma de verificar es esperar varios días y, si no vuelve a ocurrir, esto puede significar que está solucionado.
— lupincho
No funcionó, solo tuve un problema para apagar la máquina.
— lupincho
1
  1. ¿Tiene 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 intentado reparar los permisos y comprobar la integridad del archivo?

Espero que estos ayuden.

— David DelMonte
fuente
Reparé permisos. Sin periféricos, ni siquiera un cable de Ethernet. Agregará esa información a la pregunta.
— lupincho
Periféricos: siempre es bueno tener en cuenta cuando (como en la pregunta de lupincho) hay un olor a problema con 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, en la integridad: ¿Qué software libre o de código abierto se puede utilizar con el hardware de Mac para verificar la integridad de todos los bloques de un disco en el que se utiliza núcleo de almacenamiento? - demasiada tecnojerigonza allí en el momento, con el tiempo que debe condensarse a algo mucho más simple.)
— Graham Perrin el
1

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 hardware.

  2. Intente recrear el problema simplemente usando 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 de los dispositivos portátiles SMC en Mac con una batería que puede quitar

Apaga el ordenador. Desconecte el adaptador de corriente MagSafe de la computadora, si está conectado. Retirar la batería. Mantenga presionado el botón de encendido durante 5 segundos. Suelta 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.

— David DelMonte
fuente
Votado principalmente por su idea (1). Para la idea (2), con los síntomas descritos actualmente, personalmente no sospecharía ninguna diferencia con la energía de la batería sola. Sin embargo, problemas como el lupincho son sorprendentemente difíciles de diagnosticar sin acceso directo ... así que no es una mala idea. Idea (3), los problemas resueltos mediante un reinicio son (para mí) extremadamente raros ... pero, de nuevo, no es una mala idea: rápida y simple de realizar, por lo que esto también gana mi voto.
— Graham Perrin el
1

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 lo pruebes. Para eliminarlo correctamente, descargue el instalador LS nuevamente. Ejecute el instalador, pero seleccione desinstalar.

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

— David DelMonte
fuente
— Graham Perrin el
Por favor: ¿la computadora de tu amigo ejecutó Lion o Mountain Lion? ¿Qué versión de Little Snitch se desinstaló?
— Graham Perrin el
1
Ese fue Lion. No sé la versión LS ... lo siento.
— David DelMonte
1
No hay pruebas de que LS esté causando eso y desafortunadamente, debido a que el problema no ocurre cada vez, probar esto con LS eliminado tomarí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.
— lupincho
Para propósitos de resolución de problemas, Little Snitch puede ser tratado de manera diferente a otros KEXT de terceros por al menos dos razones: (i) la precocidad 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.
— Graham Perrin el
0

Mi novia simplemente había borrado los directorios para obtener 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 largos problemas de arranque.

Menciono esto porque los paralelos son una causa conocida de muchas botas lentas y parece que no es tan fácil de desinstalar como lo indica su sitio web (simplemente arrastrando y soltando el directorio).

Felices senderos, espero que esto ayude a alguien.

— Lira
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.