|
|
All the news now and in your digital future
(OT) My Mac Pro won't shut down.
Posted by Chuck Spaulding
|
Re: (OT) My Mac Pro won't shut down. October 04, 2009 01:20PM |
What do you mean by doesn't shut down?
Press Apple Option Esc. What programs are still running?
www.strypesinpost.com
Press Apple Option Esc. What programs are still running?
www.strypesinpost.com
|
Re: (OT) My Mac Pro won't shut down. October 04, 2009 05:03PM |
Chuck mate - just hold the power key until it shuts down. Quit all the apps and you should be fine.
Then restart and run Onyx [www.titanium.free.fr] and repair permissions and delete the font caches and the boot and kernel caches.
Also reset the PRAM.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
Then restart and run Onyx [www.titanium.free.fr] and repair permissions and delete the font caches and the boot and kernel caches.
Also reset the PRAM.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
|
Re: (OT) My Mac Pro won't shut down. October 04, 2009 05:08PM |
Check the console utility for error messages in the system or console log. Open up a terminal window, type "sudo halt," and put in your password. If you get an error message, you'll know what's wrong.
Holding down the power key is not a good way to shut down your system. It should be avoided unless it's the only option, like in the case of a kernel panic or a system that's totally wedged and non-responsive.
Luv ya, Ben, but repairing permissions and deleting caches will have absolutely no effect on this problem. And since the NVRAM on a Mac Pro only affects the system controller and not the live operating system, that won't change anything either.
Holding down the power key is not a good way to shut down your system. It should be avoided unless it's the only option, like in the case of a kernel panic or a system that's totally wedged and non-responsive.
Luv ya, Ben, but repairing permissions and deleting caches will have absolutely no effect on this problem. And since the NVRAM on a Mac Pro only affects the system controller and not the live operating system, that won't change anything either.
|
Re: (OT) My Mac Pro won't shut down. October 04, 2009 05:16PM |
After a hard reset is it not a good idea to wipe the caches?
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
|
Re: (OT) My Mac Pro won't shut down. October 04, 2009 05:49PM |
It's not that it's a bad idea, it's just not a helpful idea. It's like suggesting that somebody whose fuel line is cut should remove the maps from his glove box in order to get his car running again.
Mac OS X creates several different types of caches at the system level to speed up booting and login operations. When people say "system cache," they're usually referring to the kernel extension cache, which exists solely to make booting faster. This cache is only used during the very early boot process, while your screen is still solid gray with the Apple logo on it. If this cache isn't present, it'll be rebuilt during the next boot cycle, which is why sometimes your Mac takes a really long time to start up.
There are some other caches, like the Launch Services cache for instance. You can wipe it if you want, but Launch Services does a very specific task, and problems with it are extremely easy to identify. There's no such thing as a weird problem caused by Launch Services.
Mac OS X is actually a very simple operating system. Unlike Windows, for example, it's not monolithic at all. The different functions of the OS are divided into lots of different little chunks, each doing a specific job. That makes it, compared to Windows or even to other, older types of UNIX, ridiculously easy to troubleshoot.
For instance, if your Mac won't shut down, there are a limited number of things that could be wrong. To understand them, we have to look at the normal shutdown process. It goes like this:
1. The user selects "Shut down" from the Apple menu.
2. The foreground application passes an Apple Event to the loginwindow process.
3. The loginwindow process posts the confirmation alert and handles the user's response.
4. If the user confirms, or the confirmation dialog times out, loginwindow kills all running applications. In Leopard and before, loginwindow sends a Quit Application Apple Event. If I remember right, Snow Leopard changed this to speed things up, so now loginwindow sends an unblockable kill signal to the running processes, except for those that are marked dirty.
5. The loginwindow then powers off the system directly.
So what could be going wrong here? Either the foreground application isn't passing the correct Apple Event to loginwindow, or loginwindow itself is failing somewhere along the line. Typing "sudo halt" skips all that, killing all running applications (whether they're marked dirty or not, so save your changes first) and synching disk writes and powering off the system. If that succeeds, we'll know the problem lies with the foreground app or with loginwindow.
If the problem isn't with the foreground app ? that is, if choosing "Shut down" from the Apple menu with some other application in the foreground also has no result ? then it's a loginwindow problem. Where's the loginwindow problem? We can tell by watching what happens. Does the confirmation alert appear? If so, then loginwindow is both receiving and handling the shutdown Apple Event, and the problem lies somewhere downstream. Along the way, as we diagnose, we're keeping a close eye on the system and console logs to see what the OS is telling us.
And so on, and so on, until the problem's solved.
I don't mean to sound snotty here, but that is how you troubleshoot a Mac OS X system, folks. The whole "repair permissions, zap your PRAM, rebuild your Desktop file" cargo-cult crap really gets under my skin. Twenty years ago that's all we could do to fix a malfunctioning Mac, because the old Mac OS was not designed to be maintained by a human being. Mac OS X is architected from the lowest levels up to be taken care of by a person, by somebody who has a basic, functional understanding of how the system is supposed to work. And it's not like that understanding is hard to come by; Mac OS X is also one of the most thoroughly documented operating systems on the planet. And I say that with the perspective of somebody who spent six hours this weekend trying to figure out why a Massive workstation was kernel-panicking based solely on hexadecimal PCI-bus driver debugging messages in the system log, with only years-out-of-date and incomplete-even-when-it-was-new Linux documentation to rely on. (It turned out to be a bug in the Infiniband driver, for those keeping score at home.)
My point here is that there's no place in the 21st century for a cargo-cult troubleshooting mentality. Mac OS X is designed to be a serviceable operating system, not some cryptic black box that we have to treat like it's some kind of uncooperative savant who has to be coddled just right.
Mac OS X creates several different types of caches at the system level to speed up booting and login operations. When people say "system cache," they're usually referring to the kernel extension cache, which exists solely to make booting faster. This cache is only used during the very early boot process, while your screen is still solid gray with the Apple logo on it. If this cache isn't present, it'll be rebuilt during the next boot cycle, which is why sometimes your Mac takes a really long time to start up.
There are some other caches, like the Launch Services cache for instance. You can wipe it if you want, but Launch Services does a very specific task, and problems with it are extremely easy to identify. There's no such thing as a weird problem caused by Launch Services.
Mac OS X is actually a very simple operating system. Unlike Windows, for example, it's not monolithic at all. The different functions of the OS are divided into lots of different little chunks, each doing a specific job. That makes it, compared to Windows or even to other, older types of UNIX, ridiculously easy to troubleshoot.
For instance, if your Mac won't shut down, there are a limited number of things that could be wrong. To understand them, we have to look at the normal shutdown process. It goes like this:
1. The user selects "Shut down" from the Apple menu.
2. The foreground application passes an Apple Event to the loginwindow process.
3. The loginwindow process posts the confirmation alert and handles the user's response.
4. If the user confirms, or the confirmation dialog times out, loginwindow kills all running applications. In Leopard and before, loginwindow sends a Quit Application Apple Event. If I remember right, Snow Leopard changed this to speed things up, so now loginwindow sends an unblockable kill signal to the running processes, except for those that are marked dirty.
5. The loginwindow then powers off the system directly.
So what could be going wrong here? Either the foreground application isn't passing the correct Apple Event to loginwindow, or loginwindow itself is failing somewhere along the line. Typing "sudo halt" skips all that, killing all running applications (whether they're marked dirty or not, so save your changes first) and synching disk writes and powering off the system. If that succeeds, we'll know the problem lies with the foreground app or with loginwindow.
If the problem isn't with the foreground app ? that is, if choosing "Shut down" from the Apple menu with some other application in the foreground also has no result ? then it's a loginwindow problem. Where's the loginwindow problem? We can tell by watching what happens. Does the confirmation alert appear? If so, then loginwindow is both receiving and handling the shutdown Apple Event, and the problem lies somewhere downstream. Along the way, as we diagnose, we're keeping a close eye on the system and console logs to see what the OS is telling us.
And so on, and so on, until the problem's solved.
I don't mean to sound snotty here, but that is how you troubleshoot a Mac OS X system, folks. The whole "repair permissions, zap your PRAM, rebuild your Desktop file" cargo-cult crap really gets under my skin. Twenty years ago that's all we could do to fix a malfunctioning Mac, because the old Mac OS was not designed to be maintained by a human being. Mac OS X is architected from the lowest levels up to be taken care of by a person, by somebody who has a basic, functional understanding of how the system is supposed to work. And it's not like that understanding is hard to come by; Mac OS X is also one of the most thoroughly documented operating systems on the planet. And I say that with the perspective of somebody who spent six hours this weekend trying to figure out why a Massive workstation was kernel-panicking based solely on hexadecimal PCI-bus driver debugging messages in the system log, with only years-out-of-date and incomplete-even-when-it-was-new Linux documentation to rely on. (It turned out to be a bug in the Infiniband driver, for those keeping score at home.)
My point here is that there's no place in the 21st century for a cargo-cult troubleshooting mentality. Mac OS X is designed to be a serviceable operating system, not some cryptic black box that we have to treat like it's some kind of uncooperative savant who has to be coddled just right.
|
Re: (OT) My Mac Pro won't shut down. October 04, 2009 06:23PM |
Am burning my camo cargo-cult pants and t-shirt with "Command, Option, P, and R" as you read this...
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
Sorry, only registered users may post in this forum.
