Compléter d'autres réponses

Observer le mode verbeux pendant le redémarrage ou l'arrêt

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

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

Conseil : si les choses en mode verbeux semblent ne pas progresser au-delà d'un certain point, attendez cinq minutes avant de vous lancer :

• forcer un redémarrage (Command-Control-power) ; ou
• forcer un arrêt (appuyer et maintenir la touche d'alimentation).

Si un redémarrage forcé ne réussit pas, cela peut être un autre indice de la cause du ou des problèmes.

Une question connexe, bien que non axée sur le problème : Quelqu'un peut-il interpréter les messages d'arrêt verbeux ?

Le cas orienté vers les problèmes ici devrait être plus facile à résoudre pour lupincho. Moins de feuilles de thé.

Pour démarrer en mode verbeux sans taper Command-V

Une préférence peut être enregistrée dans la NVRAM. Entrez la commande suivante dans le Terminal, et soyez prêt à entrer votre mot de passe d'administrateur :

sudo nvram boot-args="-v"

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

sysdiagnose

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

sudo sysdiagnose

Cela prend du temps, mais il n'est pas nécessaire d'examiner les résultats de tous les essais. N'y prêtez attention que si un problème survient.

Pour un cas comme celui de Lupincho :

• la course de sysdiagnose peut révéler un problème avant un redémarrage ou un arrêt
• le résultat final de sysdiagnose peut être intéressant suivant a forcé redémarrer ou s'arrêter.

Plus précisément : si une exécution de sysdiagnose ne progresse pas au-delà d'un certain point, la connaissance de ce point peut aider à cerner le 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 le allmemory partie de la sysdiagnose routine, l'estimation de deux minutes d'Apple peut être très imprécise. Soyez patient.

Si vous soupçonnez que sysdiagnose ne parvient pas à progresser au-delà d'un certain point, puis touche :

• Control-C

Si l'utilisation répétée de Control-C ne permet pas d'abandonner sysdiagnose Dans ce cas (d'après 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 de l'arrêt

Dans le Finder, allez dans :

/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 errant à l'arrêt est WindowServer

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

Si vous soupçonnez que WindowServer n'est pas tué, et que cet égarement particulier contribue à l'échec de l'arrêt : demandez-vous si un logiciel tiers fait un usage non standard du processus WindowServer.

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

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

Supposition, basée sur les résultats de launchctl.

Alors que la machine fonctionne normalement, quelle est la 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. Un antivirus, un logiciel anti-malware ?

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

Visez :

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

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

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

Suite à toute forcé redémarrage ou un arrêt forcé, vous pouvez choisir de mettre de côté une copie du plus récent des deux. Si la force est requise à plusieurs reprises, vous pouvez comparer les dossiers 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 de qualité supérieure. Little Snitch est peut-être bien écrit et largement respecté mais :

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

J'ai testé la Build 12A269 d'OS X 10.8 pendant environ deux semaines avant sa sortie, en portant une attention particulière aux éléments suivants les comportements de fermeture dans les situations difficiles . Bien que je n'aie pas regardé de vidéos 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'appuyer sur La réponse de David DelMonte

Au moins sur Mountain Lion, je vois le chargement du Little Snitch 3.0 Preview 2 (3857) très tôt - avant que la journalisation de l'arrêt ne commence . Si les choses relatives à ce texte sont pareillement fin de la période de fermeture temps, 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 générosité, une pensée finale :

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