Comment vérifier ce qui empêche MBP de s'arrêter / redémarrer normalement et le corriger? [Maintenant avec les entrées de journal]

12

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).
lupincho
la source
Connectez tous les disques normalement utilisés, effectuez les connexions de serveur de fichiers normalement utilisées, puis exécutez la mountcommande. Inclure le résultat dans votre question pourrait aider à affiner les choses.
Graham Perrin
Il n'y a pas de disques ou de connexions de serveur de fichiers normalement utilisés, je connecte des clés USB plusieurs fois par mois, mais je n'en ai pas pour le moment. J'ai exécuté 'mount' sans disque connecté, mais il n'y a rien de louche.
lupincho
S'il vous plaît, quelle version de Little Snitch? Le problème est-il reproductible avec un démarrage sécurisé ou sans Little Snitch?
Graham Perrin
Le dernier LS stable (2.5.3), pas l'aperçu de la version 3. Mais cela se produisait également avec les versions 1-2 précédentes. Je ne peux pas raisonnablement tester cela sans LS ou en mode sans échec, car cela ne se produit pas tout le temps, cela prend parfois des jours et je ne peux pas faire fonctionner la machine comme ça pendant de longues périodes. Je suppose que je vivrais avec ça pour l'instant et je passerai à Mountain Lion et je verrai ce qui se passe. Mais vos suggestions ont été très utiles et spécifiques, vous obtenez donc la prime.
lupincho
Merci! Sur la base de votre plan de mise à niveau du système d'exploitation, j'ai ajouté une section à ma réponse. La réponse la plus courte est maintenant que, par rapport à 10.7.4, 10.8 devrait être à la fois (a) moins susceptible de nécessiter la force; et (b) plus facile à diagnostiquer en cas de force.
Graham Perrin

Réponses:

6

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:

entrez la description de l'image ici

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
Graham Perrin
la source
1
Merci, activé le mode verbeux avec la commande nvram. Cependant, même après le redémarrage, il n'y a pas de shutdown_monitor.log. Il existe des fichiers launchd-shutdown.log et launchd-shutdown.log.1 (il semble que seuls les fichiers actuels et 1 précédent sont conservés, contrairement aux autres journaux), mais ils étaient là avant et je les ai examinés précédemment. Je vais vérifier les messages d'arrêt en mode détaillé, j'espère que je pourrais voir où l'arrêt / redémarrage est bloqué.
lupincho
Si un problème se reproduit, prenez une photo ou deux de la verbosité. Ne vous inquiétez pas trop de la mise au point, etc., je reconnais les points clés même avec un peu de flou. J'ai un pressentiment sur ce qui ne va pas dans votre cas, la nouvelle sysdiagnosepartie de cette réponse peut être la plus pertinente.
Graham Perrin
Note latérale: ici avec Mountain Lion j'ai /private/var/log/kernel-shutdown.log(avec des informations qui me sont utiles) mais pas /private/var/log/launchd-shutdown.log.
Graham Perrin
Merci pour le conseil «sysdiagnose», exécutez-le, tout s'est bien passé, réessayez. Comme vous l'avez dit, cela prend un certain temps, sinon je pourrais le mettre en mode déconnexion pour qu'il s'exécute à chaque fois.
lupincho
L'automatisation est tentante, mais je dois m'abstenir de créer sysdiagnoseun élément de déconnexion. Dans un cas limite, l'automatisation pourrait aggraver une situation difficile.
Graham Perrin
2

Allez dans Applications -> Utilitaires et ouvrez la console

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

revolver
la source
Je n'y vois rien d'étrange.
lupincho
Bonne réponse de Revolver. +1. Pourriez-vous copier et coller dans votre question, les entrées system.log que vous voyez après avoir demandé un arrêt - et peut-être quelques minutes avant .. Collez-les dans votre question d'origine ..
David DelMonte
J'ai parcouru system.log plusieurs fois dans le passé et je n'ai rien trouvé d'inhabituel par rapport aux arrêts gracieux. Attendra la prochaine fois lorsque cela se produira et vérifiera à nouveau les journaux. J'aurais dû préciser que je suis au courant des journaux à usage général, je les mettrai à jour dans mon message d'origine.
lupincho
2

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
Lri
la source
Je l'exécute et ne montre rien. Le problème est qu'après avoir lancé l'arrêt / le redémarrage, je ne peux exécuter aucune commande. De plus, le problème n'apparaît pas toujours, donc je devrais le vérifier fréquemment ou écrire un script pour enregistrer les informations dans un fichier afin qu'après un arrêt / redémarrage problématique, je puisse revenir à ce fichier et voir si quelque chose est apparu . Mais cela semble être un bon point de départ, merci beaucoup!
lupincho
1

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.

bogdansrc
la source
C'est intéressant; fait cela, voyons ce qui se passe. Le problème est que cela ne se produit pas à chaque fois, donc la seule façon de vérifier est d'attendre plusieurs jours et si cela ne se reproduit pas, cela peut signifier qu'il est corrigé.
lupincho
Cela n'a pas fonctionné, j'ai juste eu un problème pour arrêter la machine.
lupincho
1
  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.

David DelMonte
la source
J'ai réparé les autorisations. Pas de périphériques, pas même un câble Ethernet. Ajoutera cette information à la question.
lupincho
Périphériques - toujours bon à considérer quand (comme dans la question de lupincho) il y a une odeur de problème avec les E / S. Autorisations - à mon humble avis, jamais susceptible d'empêcher un arrêt du système d'exploitation. Désintégration - possible, mais pour moi la question dans sa forme actuelle sent plus un problème avec le logiciel. (Note latérale, sur l'intégrité: quel logiciel gratuit ou open source puis-je utiliser avec le matériel Mac pour vérifier l'intégrité de chaque bloc d'un disque où Core Storage est utilisé? - trop de technobabble là pour le moment, finalement il devrait se condenser en quelque chose de beaucoup plus simple.)
Graham Perrin
1

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.

David DelMonte
la source
A voté principalement pour votre idée (1). Pour l'idée (2), avec les symptômes tels que décrits actuellement, personnellement, je ne soupçonnerais aucune différence avec la puissance de la batterie seule. Cependant, des problèmes tels que le lupincho sont étonnamment difficiles à diagnostiquer sans accès direct… ce n'est donc pas une mauvaise idée. Idée (3), les problèmes résolus par une réinitialisation sont (pour moi) extrêmement rares… mais là encore ce n'est pas une mauvaise idée - rapide et simple à réaliser donc cela aussi, gagne mon vote.
Graham Perrin
1

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

David DelMonte
la source
Pas encore dans la question, Little Snitch a d'abord été mentionné dans (plus) de commentaires à une réponse.
Graham Perrin
S'il vous plaît: l'ordinateur de votre ami dirigeait-il Lion ou Mountain Lion? Quelle version de Little Snitch a été désinstallée?
Graham Perrin
1
C'était Lion. Je ne connais pas la version LS .. désolé.
David DelMonte
1
Il n'y a aucune preuve que LS cause cela et malheureusement, parce que le problème ne se produit pas à chaque fois, tester cela avec LS retiré prendrait plusieurs jours pendant lesquels je ne peux pas perdre LS. Quant à la raison de l'exécution de LS: il y a trop de programmes qui téléphonent à la maison et ce n'est qu'un autre niveau de contrôle pour le trafic sortant. Ce que je ferais finalement, c'est de passer à la version 3 lors de sa sortie officielle.
lupincho
À des fins de dépannage, Little Snitch peut être traité différemment des autres KEXT tiers pour au moins deux raisons: (i) la précocité de sa charge, et (ii) son placement dans le domaine système à l'adresse /System/Library/Extensions. Grâce à David, j'ai ajouté une section à ma réponse.
Graham Perrin
0

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.

Lyra
la source