Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

And hopefully really final edit: After upgrading to Mountain Lion, the issue seems fixed, hopefully permanently.

Final Edit: The problem doesn't happen all the time, sometimes I have to wait several days for it to occur. So it is hard to test under different conditions (i.e. safe mode or with some software disabled) and I've decided that it is not worth spending days truing different conditions in order to on fix this. Graham Perrin's suggestions were the most helpful for finding specific information about restart/reboot issues, not found in the general-purpose logs.

Some log entries are in Edit at the bottom:

Mid-2010 15in MacBook Pro, running OS X 10.7.4. Sometimes when trying to restart or shutdown the machine, it won't work -- the screen turns gray, the spinning wheel shows, but the machine doesn't power down so after several minutes I have to shut down the machine by pressing the power button.

It doesn't happen every time, and I can't relate any software used during the session with the problem. In fact, when testing this, sometimes this would happen when I try to shutdown the machine immediately after starting it.

How to check what is preventing the graceful shutdown/restart? I assume that I have to look in some log files, but I am not sure which ones and what to look for.

Edit: Added the verbose start/shutdown setting in the nvram as suggested by Graham Perrin, and eventually the machine got stuck on reboot. I saw some verbose entries on the screen and after rebooting found them in in /var/log/launchd-shutdown.log. It appears that WindowServer may have something to do with it. Below is the end of that log file with the first 3 columns removed (the first had some increasing integer numbers, the second had entries of "1" and the third -- "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).
share|improve this question
    
Connect any normally used disks, make any normally used file server connections, then please run the mount command. Including the result in your question might help to narrow things down. –  Graham Perrin Jul 29 '12 at 13:09
    
There are no normally used disks or file server connections, I am connecting USB drives couple of times per month, but I don't have any to try right now. I did run 'mount' without any disk connected, but there is nothing fishy. –  lupincho Jul 29 '12 at 13:25
    
Please, which version of Little Snitch? Is the problem reproducible with safe boot, or without Little Snitch? –  Graham Perrin Aug 2 '12 at 0:23
    
The latest stable LS (2.5.3), not the preview of version 3. But this was happening with previous 1-2 versions too. I can't reasonably test this without LS or in safe mode, as this doesn't happen all the time, sometimes it takes days to happen and I can't run the machine like that for extended periods of time. I guess, I would live with this for now, and will upgrade to Mountain Lion and see what happens. But your suggestions were most helpful and specific, thus you get the bounty. –  lupincho Aug 2 '12 at 5:12
    
Thanks! Based on your plan to upgrade the OS, I added a section to my answer. The shortest answer now is that compared to 10.7.4, 10.8 should be both (a) less likely to require force; and (b) easier to diagnose in case of force. –  Graham Perrin Aug 2 '12 at 7:28

7 Answers 7

up vote 3 down vote accepted
+50

Complementing other answers …


Observe verbose mode during restart or shut down

Mac OS X: How to start up in single-user or verbose mode

– if you start in verbose mode, then restart or shut down will be similarly verbose.

Hint: if things in verbose mode seem to not progress beyond a certain point, allow maybe five minutes before either:

  • forcing a restart (Command-Control-power); or
  • forcing a shutdown (press and hold the power key).

If a forced restart does not succeed, that could be another clue to the cause of the problem(s).

A related question, albeit not problem-oriented: Can anyone interpret verbose shutdown messages?

The problem-oriented case here should be easier to resolve for lupincho. Fewer tea leaves.

To start in verbose mode without keying Command-V

A preference can be stored in NVRAM. Enter the following command in Terminal, and be prepared to enter your admin password:

sudo nvram boot-args="-v"

The next start of the system will be verbose.


sysdiagnose

Before each restart or shutdown, in Terminal:

sudo sysdiagnose

It's time consuming, but you need not investigate the results of all runs. Pay attention only if a problems arises.

For a case such as lupincho's:

  • the run of sysdiagnose may reveal a problem before a restart or shut down
  • the end result of sysdiagnose may be of interest following a forced restart or shut down.

More specifically: if a run of sysdiagnose fails to progress beyond a certain point, knowing that point can help to gain a sense of the underlying problem.

During the run you can use the following key combination, repeatedly, to see whether things are progressing:

  • Control-T

For the allmemory part of the sysdiagnose routine, Apple's two minute estimate may be wildly inaccurate. Be patient.

If you suspect that sysdiagnose fails to progress beyond a certain point, then key:

  • Control-C

If repeated use of Control-C fails to abort sysdiagnose, then (in my experience with Mountain Lion) it's almost certain that an attempt to restart or shut down the operating system will fail.


Shutdown monitoring

In Finder, go to:

/private/var/log/shutdown_monitor.log

This file is typically empty, but may contain items of interest following a problematic shutdown. (I have little experience in this area.)

If the only stray process at shutdown is WindowServer

It's not unusual to have stray processes at shutdown. A stray can be problematic only if it is not killed.

If you suspect that WindowServer is not killed, and that this particular stray is contributory to shutdown failure: ask yourself whether any third party software makes nonstandard use of the WindowServer process.

Quick Look of a GrabFS view of WindowServer on Mountain Lion, with two displays:

enter image description here

If Lion is similar, then my gut feeling is that the cause of shutdown failures lies beyond WindowServer.


Guesswork, based upon results of launchctl

Whilst the machine is running normally, what response to the following command?

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

Wonder whether any non-Apple software is contributory to the problem. Anti-virus, anti-malware software?


Following an upgrade from Lion to Mountain Lion

Aim for:

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

It seems the default is one log per shut down, with a maximum of two so there's also:

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

Following any forced restart or forced shut down, you might choose to set aside a copy of the most recent of the two. If force is required on any more than one occasion, you can compare files to see whether a pattern emerges.

Generally

Don't rule out the possibility of an issue with third party software, even release quality. Little Snitch may be well written and widely respected but:

  • when problems such as the one in this question become extended or too puzzling, any non-Apple kernel extension deserves attention.

I tested Build 12A269 of OS X 10.8 for around two weeks before it was released, with particular attention to shut down behaviours in difficult situations. Whilst I have not watched any videos from WWDC 2012, I do have a sense that Apple has worked very hard to prevent the need for force in all but the most difficult situations.

Building upon David DelMonte's answer

At least on Mountain Lion, I see the load of Little Snitch 3.0 Preview 2 (3857) very early – before shutdown logging begins. If things relating to this KEXT are similarly late around shutdown time, then maybe an issue will be not evident in the usual log files on disk.


If ever you discover the cause of the problem – with either Lion or Mountain Lion – I'll be pleased to know.

In the meantime, with big thanks for the bounty, a closing thought:

kextstat -l | grep --invert-match com.apple
share|improve this answer
1  
Thanks, enabled the verbose mode with the nvram command. However, even after restarting there is no shutdown_monitor.log. There are files launchd-shutdown.log and launchd-shutdown.log.1 (it seems that only the current and 1 previous of these are kept, unlike other logs), but these were there before and I looked at them previously. I will be checking the verbose mode shutdown messages, hopefully I could see where the shutdown/restart gets stuck. –  lupincho Jul 29 '12 at 12:31
    
If a problem recurs, take a photo or two of the verbosity. Don't worry too much about focus etc., I'll recognise key points even with some blur. I have a hunch about what's wrong in your case, the new sysdiagnose part of this answer may be most relevant. –  Graham Perrin Jul 29 '12 at 12:57
    
Side note: here with Mountain Lion I have /private/var/log/kernel-shutdown.log (with information that is useful to me) but not /private/var/log/launchd-shutdown.log. –  Graham Perrin Jul 29 '12 at 13:07
    
Thanks for the 'sysdiagnose' hint, just run it, went fine, will try it again. As you said, it takes some time, otherwise I could put it in logout hook to run every time. –  lupincho Jul 29 '12 at 13:09
    
Automation is tempting, but I should refrain from making sysdiagnose a logout item. In an edge case, the automation could make a difficult situation worse. –  Graham Perrin Jul 29 '12 at 13:12

Go to Applications -> Utilities, and open Console

Take a look at the system.log file, you might be able to find something there.

share|improve this answer
    
I don't see anything strange there. –  lupincho Jul 24 '12 at 10:43
    
Good answer by Revolver. +1. Could you copy and paste into your question, the system.log entries that you see after you request a shutdown - and maybe a few minutes before.. Paste them into your original question.. –  David DelMonte Jul 24 '12 at 17:46
    
I went over system.log several times in the past and didn't find anything unusual compared to graceful shutdowns. Will wait for the next time when this happens and will check the logs again. I should've clarified that I am aware of the general purpose logs, will update that in my original post. –  lupincho Jul 25 '12 at 8:13

pmset -g assertions gets a summary of power 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" 

You can see the path of a process with 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
share|improve this answer
    
I run it and shows nothing. The problem is that after I initiate shutdown/restart I can't run any commands. Also the issue doesn't appear always, so I would have to check this frequently, or write a script to save the info in a file so that after a problematic shutdown/restart I can get back to that file and see if anything showed up. But that seems like a good starting point, thanks a lot! –  lupincho Jul 25 '12 at 8:19

I've used to have this problem and did find a fix that worked for me. Although I'm not directly answering your question (how to check what's causing the problem), it's a fix that might be worth a shot:

  1. Navigate to "Macintosh HD > Library"
  2. Delete the folder named "Java"
  3. Empty Trash
  4. Shut down
  5. Once you run anything Java-related, you will be prompted to reinstall Java, do that.

After that, shutdown time should improve. Note: I'm still getting slow shutdowns when I shutdown immediately after the system starts, so after you follow the steps and want to test, wait a few minutes after the system starts before shutting down.

share|improve this answer
    
That's interesting; did that, let's see what happens. The issue is that it doesn't happen every time, so the only way to verify is to wait several days and if it doesn't happen again, this may mean that it is fixed. –  lupincho Jul 28 '12 at 20:17
    
It didn't work, just got a problem shutting down the machine. –  lupincho Jul 29 '12 at 8:05
  1. Do you have any peripheral equipment connected (USB, FW, etc)?

If so, it would be interesting to disconnect everything and see if the problem exists.

  1. Have you tried repairing permissions, and checking file integrity?

Hope these help.

share|improve this answer
    
I did repair permissions. No peripherals, not even an ethernet cable. Will add that info to the question. –  lupincho Jul 29 '12 at 14:10
    
Peripherals – always good to consider when (as in lupincho's question) there's a scent of an issue with I/O. Permissions – IMHO never likely to prevent a shut down of the OS. Disintegration – possible, but to me the question in its current form smells more of an issue with software. (Side note, on integrity: What free or open source software can I use with Mac hardware to verify integrity of every block of a disk where Core Storage is used? – too much technobabble there at the moment, eventually it should condense to something much simpler.) –  Graham Perrin Aug 2 '12 at 7:44

Some more ideas:

  1. Create another user account. Log in only as this test account. If you don't have the problem, it's likely to be something in your user software. If you do have the problem, it's possible it could be hardware.

  2. Try to recreate the problem just using battery power.

  3. Follow the steps for Apple's System Management controller -

Resetting the System Management Controller (SMC) Resetting the SMC on Mac portables with a battery you can remove

Shut down the computer. Disconnect the MagSafe power adapter from the computer, if it's connected. Remove the battery. Press and hold the power button for 5 seconds. Release the power button. Reconnect the battery and MagSafe power adapter. Press the power button to turn on the computer.

share|improve this answer
    
Voted up primarily for your idea (1). For idea (2), with the symptoms as currently described, personally I wouldn't suspect any difference with battery power alone. However problems such as lupincho's are surprisingly difficult to diagnose without direct access … so it's not a bad idea. Idea (3), problems solved by a reset are (to me) extremely rare … but again it's not a bad idea – quick and simple to perform so this, too, gains my vote. –  Graham Perrin Aug 2 '12 at 7:38
    
Thanks Graham.. –  David DelMonte Aug 2 '12 at 9:42

I didn't realize you had Little Snitch running. I just solved a similar issue for a friend, by removing LS. I suggest you try that. To remove properly, download the LS installer again. Run the installer, but select uninstall.

I'm curious too why you would want to use this app..

share|improve this answer
    
Not yet in the question, Little Snitch was first mentioned in (more) commentary to an answer. –  Graham Perrin Aug 2 '12 at 11:09
    
Please: did your friend's computer run Lion, or Mountain Lion? Which version of Little Snitch was uninstalled? –  Graham Perrin Aug 2 '12 at 11:28
1  
That was Lion. I do not know the LS version.. sorry. –  David DelMonte Aug 2 '12 at 11:42
1  
There is no proof that LS is causing that and unfortunately, because the problem doesn't occur every time, testing this with LS removed would take several days during which I can't lose LS. As for the reason for running LS: there are too many programs phoning home and it's just another level of control for outgoing traffic. What I would eventually do is to upgrade to version 3 when it is officially released. –  lupincho Aug 2 '12 at 12:11
    
For troubleshooting purposes, Little Snitch may be treated differently from other third party KEXTs for at least two reasons: (i) the earliness of its load, and (ii) its placement in the System domain at /System/Library/Extensions. With credit to David I added a section to my answer. –  Graham Perrin Aug 3 '12 at 6:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.