Et, espérons-le, vraiment l'édition finale: après la mise à niveau vers Mountain Lion, le problème semble résolu, espérons-le de manière permanente.

Final Edit: Le problème ne se produit pas tout le temps, parfois je dois attendre plusieurs jours pour qu'il se produise. Il est donc difficile de tester dans différentes conditions (c'est-à-dire en mode sans échec ou avec certains logiciels désactivés) et j'ai décidé que cela ne valait pas la peine de passer des jours à étudier différentes conditions afin de résoudre ce problème. Les suggestions de Graham Perrin ont été les plus utiles pour trouver des informations spécifiques sur les problèmes de redémarrage / redémarrage, introuvables dans les journaux à usage général.

Certaines entrées de journal sont dans Modifier en bas:

Mi-2010 15in MacBook Pro, exécutant OS X 10.7.4. Parfois, lorsque vous essayez de redémarrer ou d'arrêter la machine, cela ne fonctionne pas - l'écran devient gris, la roue qui tourne, mais la machine ne s'éteint pas, donc après plusieurs minutes, je dois arrêter la machine en appuyant sur le bouton d'alimentation bouton.

Cela ne se produit pas à chaque fois et je ne peux pas relier le logiciel utilisé pendant la session au problème. En fait, lors du test, cela se produit parfois lorsque j'essaie d'arrêter la machine immédiatement après l'avoir démarrée.

Comment vérifier ce qui empêche l'arrêt / redémarrage normal? Je suppose que je dois rechercher dans certains fichiers journaux, mais je ne sais pas lesquels et quoi rechercher.

Edit: Ajout du paramètre de démarrage / arrêt détaillé dans le nvram comme suggéré par Graham Perrin, et finalement la machine s'est bloquée au redémarrage. J'ai vu des entrées verbeuses à l'écran et après le redémarrage, je les ai trouvées dans /var/log/launchd-shutdown.log. Il semble que WindowServer puisse y être pour quelque chose. Ci-dessous se trouve la fin de ce fichier journal avec les 3 premières colonnes supprimées (la première avait des nombres entiers croissants, la seconde avait des entrées de "1" et la troisième - "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).

Compléter les autres réponses…

Observer le mode détaillé lors du redémarrage ou de l'arrêt

Mac OS X: comment démarrer en mode mono-utilisateur ou verbeux

- si vous démarrez en mode verbeux, le redémarrage ou l'arrêt sera également verbeux.

Astuce: si les choses en mode verbeux semblent ne pas progresser au-delà d'un certain point, attendez peut-être cinq minutes avant:

• forcer un redémarrage (Command-Control-power); ou
• forçant un arrêt (maintenez la touche marche / arrêt enfoncée).

Si un redémarrage forcé échoue, cela pourrait être un autre indice de la cause du ou des problèmes.

Une question connexe, bien qu'elle ne soit pas axée sur les problèmes: quelqu'un peut-il interpréter des messages d'arrêt détaillés?

Le cas orienté problème devrait être plus facile à résoudre pour le lupincho. Moins de feuilles de thé.

Pour démarrer en mode verbeux sans taper sur Commande-V

Une préférence peut être stockée dans NVRAM. Entrez la commande suivante dans Terminal et préparez-vous à entrer votre mot de passe administrateur:

sudo nvram boot-args="-v"

Le prochain démarrage du système sera détaillé.

sysdiagnose

Avant chaque redémarrage ou arrêt, dans le terminal:

sudo sysdiagnose

Cela prend du temps, mais vous n'avez pas besoin d'examiner les résultats de toutes les exécutions. Faites attention uniquement en cas de problème.

Pour un cas comme celui de lupincho:

• l'exécution de sysdiagnosepeut révéler un problème avant un redémarrage ou un arrêt
• le résultat final de sysdiagnose peut être intéressant après un redémarrage forcé ou un arrêt.

Plus précisément: si une série de sysdiagnosene parvient pas à progresser au-delà d'un certain point, le savoir peut aider à se faire une idée du problème sous-jacent.

Pendant l'exécution, vous pouvez utiliser la combinaison de touches suivante, à plusieurs reprises, pour voir si les choses progressent:

• Control-T

Pour la allmemorypartie de la sysdiagnoseroutine, l'estimation de deux minutes d'Apple peut être extrêmement inexacte. Sois patient.

Si vous pensez que cela sysdiagnosene progresse pas au-delà d'un certain point, saisissez:

• Contrôle-C

Si l'utilisation répétée de Control-C échoue sysdiagnose, alors (selon mon expérience avec Mountain Lion), il est presque certain qu'une tentative de redémarrage ou d'arrêt du système d'exploitation échouera.

Surveillance d'arrêt

Dans le Finder, accédez à:

/private/var/log/shutdown_monitor.log

Ce fichier est généralement vide, mais peut contenir des éléments d'intérêt suite à un arrêt problématique. (J'ai peu d'expérience dans ce domaine.)

Si le seul processus parasite à l'arrêt est WindowServer

Il n'est pas rare d'avoir des processus parasites à l'arrêt. Un parasite ne peut être problématique que s'il n'est pas tué.

Si vous pensez que WindowServer n'est pas tué et que cette erreur particulière contribue à l'échec de l'arrêt: demandez-vous si un logiciel tiers fait un usage non standard du processus WindowServer.

Aperçu rapide d'une vue GrabFS de WindowServer sur Mountain Lion, avec deux écrans:

Si Lion est similaire, mon sentiment profond est que la cause des échecs d'arrêt se situe au-delà de WindowServer.

Devinez, basé sur les résultats de launchctl

Alors que la machine fonctionne normalement, quelle réponse à la commande suivante?

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

Je me demande si un logiciel non Apple contribue au problème. Logiciel anti-virus, anti-malware?

Après une mise à niveau de Lion vers Mountain Lion

Viser:

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

Il semble que la valeur par défaut soit un journal par arrêt, avec un maximum de deux, il y a donc aussi:

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

Après un redémarrage forcé ou un arrêt forcé, vous pouvez choisir de mettre de côté une copie de la plus récente des deux. Si la force est requise à plusieurs reprises, vous pouvez comparer les fichiers pour voir si un modèle émerge.

Généralement

N'excluez pas la possibilité d'un problème avec un logiciel tiers, même la qualité des versions. Little Snitch peut être bien écrit et largement respecté mais:

• lorsque des problèmes tels que celui de cette question deviennent étendus ou trop déroutants, toute extension du noyau non Apple mérite l'attention.

J'ai testé la version 12A269 d'OS X 10.8 pendant environ deux semaines avant sa sortie, avec une attention particulière pour arrêter les comportements dans les situations difficiles . Bien que je n'aie regardé aucune vidéo de la WWDC 2012, j'ai le sentiment qu'Apple a travaillé très dur pour éviter le recours à la force dans toutes les situations, sauf les plus difficiles.

S'appuyant sur la réponse de David DelMonte

Au moins sur Mountain Lion, je vois la charge de Little Snitch 3.0 Preview 2 (3857) très tôt - avant que la journalisation de l'arrêt ne commence . Si les choses liées à ce KEXT sont également en retard vers l' heure d' arrêt , alors peut-être qu'un problème ne sera pas évident dans les fichiers journaux habituels sur le disque.

Si jamais vous découvrez la cause du problème - avec Lion ou Mountain Lion - je serai heureux de le savoir.

En attendant, avec un grand merci pour la prime, une pensée de clôture:

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

Allez dans Applications -> Utilitaires et ouvrez la console

Jetez un œil au fichier system.log, vous pourrez peut-être y trouver quelque chose.

pmset -g assertions obtient un résumé des affirmations de pouvoir:

$ 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" 

Vous pouvez voir le chemin d'un processus avec 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

J'ai eu ce problème et j'ai trouvé un correctif qui fonctionnait pour moi. Bien que je ne réponde pas directement à votre question (comment vérifier la cause du problème), c'est une solution qui pourrait valoir le coup:

1. Accédez à "Macintosh HD> Bibliothèque"
2. Supprimez le dossier nommé "Java"
3. Poubelle vide
4. Fermer
5. Une fois que vous exécutez quelque chose lié à Java, vous serez invité à réinstaller Java, faites-le.

Après cela, le temps d'arrêt devrait s'améliorer. Remarque: je reçois toujours des arrêts lents lorsque je m'arrête immédiatement après le démarrage du système.Après avoir suivi les étapes et voulu tester, attendez quelques minutes après le démarrage du système avant de vous arrêter.

1. Avez-vous un équipement périphérique connecté (USB, FW, etc.)?

Si c'est le cas, il serait intéressant de tout déconnecter et de voir si le problème existe.

1. Avez-vous essayé de réparer les autorisations et de vérifier l'intégrité des fichiers?

J'espère que ces aides.

Quelques idées supplémentaires:

1. Créez un autre compte utilisateur. Connectez-vous uniquement en tant que compte de test. Si vous n'avez pas le problème, il est probable que ce soit quelque chose dans votre logiciel utilisateur. Si vous avez le problème, il est possible que ce soit du matériel.

2. Essayez de recréer le problème en utilisant uniquement la batterie.

3. Suivez les étapes pour le contrôleur de gestion du système d'Apple -

Réinitialisation du contrôleur de gestion du système (SMC) Réinitialisation du SMC sur les portables Mac avec une batterie que vous pouvez retirer

Éteindre l'ordinateur. Débranchez l'adaptateur secteur MagSafe de l'ordinateur, s'il est connecté. Retirez la batterie. Appuyez sur le bouton d'alimentation et maintenez-le enfoncé pendant 5 secondes. Relâchez le bouton d'alimentation. Rebranchez la batterie et l'adaptateur secteur MagSafe. Appuyez sur le bouton d'alimentation pour allumer l'ordinateur.

Je n'avais pas réalisé que Little Snitch était en cours d'exécution. Je viens de résoudre un problème similaire pour un ami, en supprimant LS. Je vous suggère d'essayer cela. Pour supprimer correctement, téléchargez à nouveau l'installateur LS. Exécutez le programme d'installation, mais sélectionnez désinstaller.

Je suis aussi curieux de savoir pourquoi vous souhaitez utiliser cette application ..

Ma copine avait simplement supprimé les répertoires pour les parallèles en faisant glisser et en déposant le répertoire dans la poubelle et en vidant la corbeille. Cependant, j'ai trouvé à nouveau des parallèles dans le dossier Library, et il y avait un script shell (fichier .sh) pour le désinstaller correctement. Cela a fonctionné et résolu nos longs problèmes de démarrage.

Je mentionne cela parce que les parallèles sont une cause connue de nombreux démarrages lents et il semble que ce ne soit pas aussi facile à désinstaller que leur site Web l'indique (il suffit de glisser-déposer le répertoire).

Sentiers heureux, j'espère que cela aide quelqu'un.