如何检查阻止MBP正常关闭/重新启动的原因并进行修复？[现在有日志条目]

12

并希望最终进行真正的编辑：升级到Mountain Lion之后，该问题似乎已解决，希望永久存在。

最终编辑：问题不会一直发生，有时我必须等待几天才能发生。因此，很难在不同的条件下（即安全模式或禁用某些软件）进行测试，我认为花数天时间在不同的条件下进行修复是不值得的。Graham Perrin的建议对于查找有关重新启动/重新启动问题的特定信息（在通用日志中找不到）最有帮助。

一些日志条目位于底部的“编辑”中：

2010年中15英寸MacBook Pro，运行OS X 10.7.4。有时，当尝试重新启动或关闭机器时，它将无法工作-屏幕变灰，显示纺车轮，但是机器无法关闭电源，因此几分钟后，我必须通过按电源关闭机器按钮。

这并非每次都发生，并且我无法将会话期间使用的任何软件与该问题相关联。实际上，在测试时，有时在启动计算机后立即尝试关闭计算机时会发生这种情况。

如何检查阻止正常关机/重启的原因？我假设我必须查看一些日志文件，但是我不确定要查找哪些文件和查找什么。

编辑：按照Graham Perrin的建议，在nvram中添加了详细的启动/关闭设置，最终计算机在重启时卡住了。我在屏幕上看到了一些详细的条目，重新启动后在/var/log/launchd-shutdown.log中找到了它们。似乎WindowServer可能与此有关。以下是该日志文件的末尾，其中前三列已删除（第一列具有递增的整数，第二列具有条目“ 1”，第三列-“ 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 
— 羽扇豆
source
连接任何常用的磁盘，建立任何常用的文件服务器连接，然后运行mount命令。将结果包括在您的问题中可能有助于缩小范围。
— 格雷厄姆·佩林
没有通常使用的磁盘或文件服务器连接，我每月连接USB驱动器几次，但是现在没有任何尝试。我确实在没有连接任何磁盘的情况下运行了“ mount”，但是没有任何问题。
— lupincho，2012年
拜托，哪个版本的Little Snitch？使用安全启动或没有Little Snitch可以重现该问题吗？
— Graham Perrin
最新的稳定版LS（2.5.3），不是版本3的预览版。但是，这也发生在以前的1-2版本中。没有LS或在安全模式下，我无法进行合理的测试，因为这种情况不会一直发生，有时会花几天时间，而且我不能长时间运行机器。我猜想，我现在会接受，并将升级到Mountain Lion，看看会发生什么。但是您的建议是最有帮助和具体的，因此您会得到赏金。
— lupincho 2012年
谢谢！根据您升级操作系统的计划，我在回答中添加了一部分。现在最短的答案是，与10.7.4相比，10.8都应该（a）少用力；（b）在用力的情况下更容易诊断。
— 格雷厄姆·佩林

Answers:

6

补充其他答案...

在重新启动或关闭期间观察详细模式

Mac OS X：如何以单用户或详细模式启动

–如果以详细模式启动，则重新启动或关闭也将类似详细。

提示：如果详细模式下的事情似乎没有进展到某个特定点，则可能要等五分钟：

  • 强制重启（Command-Control-power）；要么
  • 强制关机（按住电源键）。

如果强制重启未成功，则可能是问题原因的另一个线索。

一个相关的问题，尽管不是面向问题的：任何人都可以解释冗长的关闭消息吗？

面向问题的案例对于lupincho应该更容易解决。茶叶少。

在不键入Command-V的情况下以详细模式启动

首选项可以存储在NVRAM中。在终端中输入以下命令，并准备输入管理员密码：

sudo nvram boot-args="-v"

系统的下一个启动将是冗长的。

系统诊断

在每次重新启动或关闭之前，在终端中： 

sudo sysdiagnose

这很耗时，但是您无需调查所有运行的结果。仅在出现问题时注意。

对于诸如lupincho的情况：

  • 的运行sysdiagnose可能会在重新启动或关闭之前揭示问题
  • sysdiagnose的最终结果可能会感兴趣下一个强制重启或关机。

更具体地说：如果sysdiagnose失败不能超过某个特定点，则知道该点可以帮助您了解潜在的问题。

在运行期间，您可以反复使用以下组合键来查看事情是否在进行：

  • Control-T

对于allmemory该部分sysdiagnose程序，苹果的两大分钟来估计可能是极不准确。耐心一点。

如果您怀疑sysdiagnose无法进行到一定程度，请输入以下命令：

  • Control-C

如果重复使用Control-C无法终止sysdiagnose，那么（以我对Mountain Lion的经验），几乎可以肯定的是，尝试重新启动或关闭操作系统都会失败。

关机监控

在Finder中，转到：

/private/var/log/shutdown_monitor.log

该文件通常为空，但是在出现问题的关机后可能包含感兴趣的项目。（我在这方面的经验很少。）

如果关闭时唯一的混乱过程是WindowServer

在关机时会有混乱的过程并不少见。流浪只有在不被杀死的情况下才会成为问题。

如果您怀疑WindowServer没有被杀死，并且这种特殊情况是造成关机失败的原因：请问问自己是否有任何第三方软件非标准地使用WindowServer进程。

快速查看Mountain Lion上WindowServer的GrabFS视图，有两个显示：

在此处输入图片说明

如果Lion相似，那么我的直觉是关机失败的原因不在WindowServer之外。

根据launchctl的结果进行猜测

机器正常运行时，对以下命令有何反应？ 

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

怀疑是否有非Apple软件导致该问题。防病毒，防恶意软件？

从Lion升级到Mountain Lion

目的是： 

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

似乎默认值是每次关闭一个日志，最多两个日志，因此还有： 

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

继任何强制重启或强制关闭，您可以选择搁置一份最近的两个组成。如果不止一种情况需要用力，则可以比较文件以查看是否出现图案。

通常

不排除第三方软件出现问题的可能性，甚至也不排除发行质量。Little Snitch可能写得很好并且广受尊重，但：

  • 当该问题中的一个问题变得扩展或太令人困惑时，任何非Apple内核扩展都应引起注意。

在发布之前，我对OS X 10.8的Build 12A269进行了大约两个星期的测试，特别注意在困难情况下的关闭行为。尽管我没有看过WWDC 2012的任何视频，但我确实感到，苹果在除最困难的情况以外的所有情况下都竭尽全力以防止使用武力。

以David DelMonte的答案为基础

至少在Mountain Lion上，我很早就看到了Little Snitch 3.0 Preview 2（3857）的负载-在关闭日志记录开始之前。如果与此KEXT有关的事情同样在关机时间后才出现，那么在磁盘上的常规日志文件中可能不会出现明显的问题。

如果您发现问题的起因是–使用Lion或Mountain Lion –我将很高兴知道。

在此期间，对悬赏的感谢深表谢意： 

kextstat -l | grep --invert-match com.apple
— 格雷厄姆·佩林
source
1
谢谢，使用nvram命令启用了详细模式。但是，即使重新启动后，也没有shutdown_monitor.log。有文件launchd-shutdown.log和launchd-shutdown.log.1（似乎只保留了当前文件和前1个文件，与其他日志不同），但是这些文件在此之前，我之前曾看过。我将检查详细的模式关闭消息，希望我能看到关闭/重新启动卡在哪里。
— lupincho，2012年
如果问题再次出现，请拍一张或两张详细图片。不必太担心聚焦等问题，即使有些模糊，我也会识别关键点。我对您的问题有什么预感sysdiagnose，这个答案的新部分可能最相关。
— 格雷厄姆·佩林
旁注：在这里，我拥有Mountain Lion /private/var/log/kernel-shutdown.log（提供对我有用的信息），但没有/private/var/log/launchd-shutdown.log。
— 格雷厄姆·佩林
感谢您的“ sysdiagnose”提示，只需运行它，一切正常，将再试一次。如您所说，这需要一些时间，否则我可以将其放入注销钩子以每次运行。
— lupincho
自动化很诱人，但我应该避免进行sysdiagnose注销。在极端情况下，自动化可能会使困难情况变得更糟。
— 格雷厄姆·佩林
2

转到应用程序->实用程序，然后打开控制台

看一下system.log文件，您也许可以在其中找到一些东西。

— 左轮手枪
source
我在那里看不到任何奇怪的东西。
— lupincho 2012年
左轮手枪的好答案。+1。您可以复制并粘贴到你的问题，SYSTEM.LOG条目，你看你要求关机后-之前也许几分钟..它们粘贴到你原来的问题..
— 大卫DelMonte
过去，我几次查看system.log，与正常关机相比，没有发现任何异常。发生这种情况时，将等待下一次，并将再次检查日志。我应该澄清一下，我知道通用日志，它将在我的原始帖子中进行更新。
— lupincho 2012年
2

pmset -g assertions 获取电源断言的摘要：

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

您可以使用以下命令查看流程的路径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
— 里
source
我运行它，什么也没显示。问题是我启动关闭/重新启动后无法运行任何命令。而且问题并不总是出现，因此我将不得不经常检查此问题，或编写脚本以将信息保存在文件中，以便在出现问题的关闭/重新启动后，我可以回到该文件并查看是否显示任何内容。但这似乎是一个很好的起点，非常感谢！
— lupincho 2012年
1

我曾经遇到过这个问题，并且确实找到了对我有用的修复程序。尽管我没有直接回答您的问题（如何检查导致问题的原因），但此修复程序值得一试：

  1. 导航到“ Macintosh HD>库”
  2. 删除名为“ Java”的文件夹
  3. 清空垃圾桶
  4. 关掉
  5. 一旦运行了任何与Java相关的内容，系统都会提示您重新安装Java。

在那之后，关闭时间应该会增加。注意：在系统启动后立即关闭时，我仍然会遇到缓慢的关闭，因此，在按照步骤进行测试后，请在系统启动后等待几分钟，然后再关闭。

— 博格丹斯
source
那很有意思; 做到了，让我们看看会发生什么。问题在于它不会每次都发生，因此唯一的验证方法是等待几天，如果再也没有发生，则可能意味着它已修复。
— lupincho 2012年
它没有用，只是在关闭机器时遇到了问题。
— lupincho 2012年
1
  1. 您是否连接了任何外围设备（USB，固件等）？

如果是这样，断开所有连接并查看是否存在问题将很有趣。

  1. 您是否尝试过修复权限并检查文件完整性？

希望这些帮助。

— 戴维·德尔蒙特
source
我没有修复权限。没有外围设备，甚至没有以太网电缆。将该信息添加到问题中。
— lupincho，2012年
外围设备–总是很高兴考虑何时（如lupincho的问题）I / O出现问题。权限– IMHO永远不会阻止操作系统关闭。分解-可能，但是对我来说，当前形式的问题更像是软件问题。（关于完整性的附带说明：我可以在Mac硬件上使用哪些免费或开源软件来验证使用Core Storage的磁盘的每个块的完整性？ –目前存在太多技术混乱，最终它应该凝聚很多东西更简单。）
— 格雷厄姆·佩林
1

一些更多的想法：

  1. 创建另一个用户帐户。仅以该测试帐户身份登录。如果您没有问题，则可能是用户软件中有问题。如果确实有问题，则可能是硬件。

  2. 尝试仅使用电池电源来重新产生问题。

  3. 遵循Apple系统管理控制器的步骤-

重置系统管理控制器（SMC） 使用可以卸下的电池在Mac便携式计算机上重置SMC

关闭计算机。如果已连接，请从计算机上断开MagSafe电源适配器的连接。取出电池。按住电源按钮5秒钟。释放电源按钮。重新连接电池和MagSafe电源适配器。按电源按钮打开计算机。

— 戴维·德尔蒙特
source
主要为您的想法投票（1）。对于想法（2），就目前所描述的症状而言，个人而言，我个人不会怀疑电池电量会有任何差异。但是，如果没有直接访问，很难诊断出羽扇豆之类的问题……因此，这不是一个坏主意。想法（3），通过重置解决的问题（对我来说）非常罕见…但这又不是一个坏主意-执行起来简单快捷，这也赢得了我的投票。
— 格雷厄姆·佩林
1

我没意识到你在跑小飞贼。我刚刚通过删除LS为朋友解决了类似的问题。我建议您尝试一下。要正确删除，请再次下载LS安装程序。运行安装程序，但选择卸载。

我也很好奇您为什么要使用此应用程序。

— 戴维·德尔蒙特
source
尚未提出问题，在（更多）评论的答案中首先提到了Little Snitch。
— 格雷厄姆·佩林
拜托：您朋友的计算机运行的是Lion还是Mountain Lion？卸载了哪个版本的Little Snitch？
— 格雷厄姆·佩林
1
那是狮子。我不知道LS版本..对不起。
— 戴维·德尔蒙特
1
没有证据表明LS会造成这种情况，不幸的是，由于问题并非每次都会发生，因此在删除LS的情况下进行测试会花费几天的时间，在此期间我不会丢失LS。至于运行LS的原因：有太多程序正在打电话给家，这只是传出流量的另一个控制级别。我最终要做的是在正式发布时升级到版本3。
— lupincho 2012年
为了进行故障排除，出于以下两个原因，可以将Little Snitch与其他第三方KEXT区别对待：（i）尽早加载，并且（ii）将其放置在System域中/System/Library/Extensions。归功于David，我在回答中添加了一部分。
— 格雷厄姆·佩林
0

我的女友只是通过将目录拖放到垃圾桶并清空垃圾桶来删除并行目录。但是，我再次在Library文件夹中找到了并行文件，并且有一个Shell脚本（.sh文件）可以正确卸载它。这可以解决我们的长时间启动问题。

我之所以这样说，是因为并行是许多启动缓慢的已知原因，而且似乎不像其网站所指示的那样容易卸载（只需拖放目录）。

幸福的足迹，希望对您有所帮助。

— 天琴座
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.