¿Cómo comprobar qué impide que el MBP se cierre / reinicie correctamente y lo solucione?

Y afortunadamente realmente edición final: después de actualizar a Mountain Lion, el problema parece estar solucionado, con suerte permanentemente.

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

Algunas inputs de logging están en Editar en la parte inferior:

A mediados de 2010 15in MacBook Pro, ejecutando OS X 10.7.4. A veces, cuando bash reiniciar o apagar la máquina, no funciona: la pantalla se vuelve gris, se muestra la rueca, pero la máquina no se apaga, así que después de varios minutos tengo que apagar la máquina presionando el button de encendido. button.

No sucede todas las veces, y no puedo relacionar ningún software utilizado durante la session con el problema. De hecho, al probar esto, a veces esto sucedería cuando intente apagar la máquina inmediatamente después de iniciarla.

¿Cómo comprobar qué impide el apagado / reinicio elegante? Supongo que tengo que search en algunos files de logging, pero no estoy seguro de cuáles y qué search.

Editar: se agregó la configuration detallada de inicio / apagado en el nvram como lo sugirió Graham Perrin, y finalmente la máquina se atascó al reiniciar. Vi algunas inputs 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 file de logging con las primeras 3 columnas eliminadas (la primera tenía algunos numbers integers crecientes, la segunda tenía inputs 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). 

  • iPhone 3gs no se enciende
  • Limpiar reinicio desde la terminal?
  • Inicio de Mac: carpeta intermitente
  • 27 "iMac (otoño de 2010) no se apagará
  • ¿Es peligroso interrumpir la optimization de la actualización posterior a OS X?
  • ¿Hay alguna manera de automatizar el reinicio con un disco de arranque diferente?
  • Arranque "desacelerado" hasta que todos los dispositivos estén disponibles
  • Sleep Wake Failures debido a watchdog el 10.13 (actualización suplementaria)
  • 8 Solutions collect form web for “¿Cómo comprobar qué impide que el MBP se cierre / reinicie correctamente y lo solucione?”

    Complementando otras respuestas …


    Observe el modo detallado durante el reinicio o apagado

    Mac OS X: cómo iniciarse en modo de usuario único o detallado

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

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

    • forzar un reinicio (Command-Control-power); o
    • forzando 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 posts 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 introducir Command-V

    Una preference se puede almacenar en NVRAM. Ingrese el siguiente command en 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 time, 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 sysdiagnose puede revelar un problema antes de un reinicio o apagado
    • el resultado final de sysdiagnose puede ser de interés luego de un reinicio forzado o apagado.

    Más específicamente: si una ejecución de sysdiagnose no progresa más allá de cierto punto, conocer ese punto puede ayudar a get 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 parte de toda la sysdiagnose rutina de sysdiagnose , la estimación de dos minutos de Apple puede ser muy inexacta. Se paciente.

    Si sospecha que sysdiagnose no puede progresar más allá de cierto punto, entonces key:

    • Control-C

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


    Monitoreo de apagado

    En Finder, ve a:

    /private/var/log/shutdown_monitor.log

    Este file normalmente 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 process de pérdida en el cierre es WindowServer

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

    Si sospecha que WindowServer no se ha destruido y que esta pérdida en particular contribuye a la falla de la desconnection: pregúntese si un software de terceros utiliza de forma no estándar el process de WindowServer.

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

    enter image description here

    Si Lion es similar, mi instinto me dice que la causa de los fallos de apagado se encuentra más allá de WindowServer.


    Guesswork, basado en los resultados de launchctl

    Mientras la máquina funciona normalmente, ¿qué respuesta tiene el siguiente command?

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

    Me pregunto si algún software que no sea de Apple contribuye al problema. Anti-virus, software anti-malware?


    Tras una mejora de León a León de montaña

    Aspirar a:

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

    Parece que el valor pnetworkingeterminado es un logging por cierre, 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 cierre forzado, puede elegir reservar una copy de la más reciente de las dos. Si se requiere fuerza en más de una ocasión, puede comparar files para ver si surge un patrón.

    En general

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

    • cuando problemas como el de esta pregunta se extienden o confunden demasiado, cualquier extensión de Kernel que no sea de Apple merece atención.

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

    Basándose en la respuesta de David DelMonte

    Al less en Mountain Lion, veo la carga de Little Snitch 3.0 Preview 2 (3857) muy temprano, antes de que comience la session de apagado . Si las cosas relacionadas con este KEXT son similares tarde en el momento del cierre , entonces tal vez un problema no sea evidente en los files de logging habituales en el disco.


    Si alguna vez descubres la causa del problema, ya sea León o León de montaña, estaré encantado de saberlo.

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

     kextstat -l | grep --invert-match com.apple 

    Vaya a Aplicaciones -> Utilidades, y abra la console

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

    pmset -g assertions obtiene un resumen de las aserciones 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 process 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 

    Solía ​​tener este problema y encontré una solución que funcionó para mí. Aunque no contesto directamente 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 haya ejecutado algo relacionado con Java, se le pedirá que reinstale Java, haga eso.

    Después de eso, el time de apagado debería mejorar. Nota: sigo recibiendo paradas lentas cuando apago inmediatamente después de que el sistema se inicia, por lo que después de seguir los pasos y desea probar, espere unos minutos después de que el sistema se encienda antes de apagarse.

    1. ¿Tiene algún equipo periférico conectado (USB, FW, etc.)?

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

    1. ¿Has intentado reparar permissions y verificar la integridad del file?

    Espero que esto ayude

    Algunas ideas más:

    1. Crea otra count de usuario Inicie session solo como esta count de testing. Si no tiene el problema, es probable que sea algo en su software de usuario. Si tienes el problema, es posible que sea hardware.

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

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

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

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

    No me di count de que tenías Little Snitch funcionando. Acabo de resolver un problema similar para un amigo, eliminando LS. Te sugiero que pruebes eso. Para eliminarlo correctamente, descargue el instalador LS nuevamente. Ejecute el instalador, pero select desinstalar.

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

    Mi novia simplemente había eliminado los directorys de paralelos al drag and drop el directory a la papelera y vaciar la basura. Sin embargo, volví a encontrar paralelismos en la carpeta Biblioteca, y había un script de shell (file .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 website (simplemente arrastrando y soltando el directory).

    Happy trails, espero que esto ayude a alguien.

    Loving Apple Products like poisoning (iPhone, iPad, iMac, Macbook, iWatch).