Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Resolving stuck application issues without a restart System
This tip may come as a no-brainer to older UNIX gurus, but to the legion of old-school Mac fans, it's a pretty new concept. Suppose your CPU crashes while in full-screen mode. For example, your screensaver or game gets stuck in a loop and your GUI refuses to respond. This is usually not the problem of the system, but the program or module being run itself. In any case, there is an easy way to regain control of your computer if a program crashes while in full-screen mode. If the program isn't in fullscreen mode, then just use command-option-escape to quit the crashed program. This solution requires access to another machine that can be networked to the troublesome machine.

Step 1:
Go to your system preferences and under your sharing panel, make sure the "remote login" is on. You can also enable telnet to do remote login, but SSH is more secure. If you are unfamiliar with command line, write down the text that OS X gives you for logging in remotely when the Remote Login item is highlighted in the sharing panel. Enabling remote login must be done before your application crashes, obviously.

Step 2:
When your screensaver or game crashes, either plug in another Mac to your ethernet port or if you are on a LAN, go to a friend's computer on the network and log into your computer using SSH or telnet from the UNIX command line (if it is a windows CPU, type "telnet" from DOS-prompt). You should notice that though the GUI is stuck, the login shell is quite autonomous from the GUI's dilemmas. If remotely logging into your CPU is a foreign concept, try it before your computer crashes. There are plenty of tutorials on command line UNIX. Just remember that the UNIX layer uses the same password and username as Aqua does.

Step 3:
Next, find the bad thread and kill it. I like to use the "top" command to find the bad thread. When you figure out which program is bad (the names and usages are listed) take down the thread ID number (the PID column in 'top'). Type kill thread_ID_number and the bad process should terminate (a thread is a running program or process). Go back to your computer and notice that the offending application has quit. No restarting of your CPU is required; once again, everything just works.

[Editor's note: I thought we already had a basic hint published on remote login for troubleshooting purposes, but I can't seem to find it ... apologies if this is a duplicate.]
    •    
  • Currently 0.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (0 votes cast)
 
[8,576 views]  

Resolving stuck application issues without a restart | 19 comments | Create New Account
Click here to return to the 'Resolving stuck application issues without a restart' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Using ps axc is easier
Authored by: brandonedling on Dec 05, '02 10:07:51AM

su to root and type "ps axc" (without the quotes) at the prompt. This will list everything. Type "kill <ID>" at the prompt and there you go.

Brandon



[ Reply to This | # ]
Question to: Using ps axc is easier
Authored by: sms on Dec 05, '02 10:22:11AM
How can I search for a specific appliction within the ps output?

I tried ps -aux |grep Microsoft but (although Microsoft Word was running and hanging) the line was empty. Making the console window bigger revealed the PID.

Thanks for any input!

sImOn

[ Reply to This | # ]
Question to: Using ps axc is easier
Authored by: brandonedling on Dec 05, '02 03:36:03PM

Many Carbon apps don't itemize properly... instead, they fall under the title of "LaunchCFMApp". Sort of a drag, and I'm not sure if there is anyway around it. That when I look at how long a process has been running and then "guess" I'm killing the right one.

Brandon



[ Reply to This | # ]
2nd Question to: Using ps axc is easier
Authored by: sms on Dec 05, '02 11:18:05AM
Interestingly I just found out that every built in application (Finder, iTunes, ...) can be found piping grep after ps:

[myhostname:~] myusername% ps -axc | grep -ie finder
422 ?? S 0:27.72 Finder

The strange thing is: any other application on my computer (Mozilla, Word, you-name-it,...) cannot be found like that, though they show up in ps and top of course!!

Any clues?

[ Reply to This | # ]
2nd Question to: Using ps axc is easier
Authored by: sharumpe on Dec 05, '02 12:36:25PM
try this:
ps -axww | grep -ie whatever
The 'ww' means to show the long string for the command, even if it has to wrap around a line. Mr. Sharumpe

[ Reply to This | # ]
Other PS options & basic HOWTO on the recovery process
Authored by: Lanir on Dec 14, '02 06:14:37AM
... You beat me to adding the ww flags. =)

Personally, I'd probably do this if I wanted to save time. If commandline is new to you, you should still be able to follow this. If it's not, skim over what you don't need.

login as the username that is logged into the Mac from another machine on the same network, then...
Note: Remember to login using the short form of your username. Find it beforehand in System Preferences under Accounts if you're likely to forget.

ps -xwwU username | less

You have to replace your username in the line above for it to work right. Try this beforehand. Yes, it looks like a lot of strange goo but it will keep you from wading through more than you need to. It also sends the output to less a pager that lets you use the up and down arrow keys to navigate. To get out of less, hit the q key. Here is a short example of what you might see on a running system:

PID TT STAT TIME COMMAND
175 ?? Ss 2:06.89 /System/Library/Frameworks/ApplicationServices.framewo
rk/Versions/A/Frameworks/ATS.framework/Versions/A/Support/ATSServer
179 ?? Ss 21:06.88 /System/Library/CoreServices/WindowServer -daemon
341 ?? Ss 0:13.52 /System/Library/CoreServices/loginwindow.app/Contents/
MacOS/loginwindow console
390 ?? Ss 0:01.37 /System/Library/CoreServices/pbs
393 ?? S 0:17.56 /System/Library/CoreServices/Dock.app/Contents/MacOS/D
ock -psn_0_393217
396 ?? S 4:11.57 /System/Library/CoreServices/SystemUIServer.app/Conten
ts/MacOS/SystemUIServer -psn_0_524289
397 ?? S 0:15.10 /System/Library/CoreServices/Finder.app/Contents/MacOS
/Finder -psn_0_655361
3125 ?? S 0:04.27 /System/Library/CoreServices/SecurityAgent.app/Content
s/MacOS/SecurityAgent
3262 p1 S 0:00.11 -tcsh (tcsh)

To parse this out right so it makes sense to you, do this. First off, ignore all but the first column (PID) and the last one (Command). Any command that starts with a slash, just ignore everything before the last slash. For the second to last line (PID 3125), you would only need to know it was SecurityAgent, for example. Anything that doesn't begin with a slash is leaving out the path and just telling you the command. The last line (PID 3262) is an example of this (ignore the dash).

After you have the Proccess ID (PID), you'll want to use the kill command to make it go away. Here's how to do it the right way. Some things are stubborn so we'll try a hitting it over the head gradually harder until it's gone.

kill -HUP PID

This will tell it to hangup, which generally allows an application time to close things gracefully. It won't always work. To test, run the previous command again and search for the application you tried to kill (ps -xwwU username | less). If you see it, note the PID again because it may be different. Then...

kill PID

This just tells it to go away. Generally works. Look again to see if it's gone yet. If not...

kill -KILL PID

Slay with extreme prejudice. Do not pass Go, do not collect $200. Just smear it first and ask questions later. Check to make sure it's gone. If that didn't work, give it about a minute and check again. If it's still there... Well, one last trick.

kill 1

This will kill all processes and send you into single-user mode without turning the machine off. I can't imagine anything hosing your system this bad and still letting you login remotely but just in case here's how to do it. If things are this bad, all you want to do once you've typed that in is give it a little bit to get into single-user mode and type:

halt

Give it a couple minutes. If your machine is warm, give it more like half an hour to an hour as this might be part of the problem (happens on PC's sometimes, especially laptops). If your system doesn't come back up cleanly and let you login, you have much more serious problems. And my sympathies, for what it's worth.

[ Reply to This | # ]
2nd Question to: Using ps axc is easier
Authored by: aranor on Dec 06, '02 12:34:10AM

That's because you used the -c switch. That shows the name of the process itself (executable name), which for CFM apps (i.e. most Carbon apps), will show 'LaunchCFMApp'. If you leave that switch off (and put in -ww to make sure the entire line is displayed) then it shows the path to the process, and you can successfully use grep on it.

Anyway, use this to get the PID of the process you want:

ps -axww | grep -i <process name>



[ Reply to This | # ]
Try ps -aux
Authored by: iroot on Dec 05, '02 04:20:39PM

For those who like lots of info



[ Reply to This | # ]
ssh can't always rescue you
Authored by: ptwithy on Dec 05, '02 11:02:49AM

Unfortunately, it seems that sometimes whatever is wedging the display also prevents ssh from logging in. I have only successfully used the ssh trick once since OS X beta.

I often find my wedged machine will respond to pings, but trying to open an ssh session just hangs (and times out).

IWBNI Apple provided some keyboard escape to get you to a shell prompt (using the raw screen that verbose booting uses) for situations like this.



[ Reply to This | # ]
One more
Authored by: Jay on Dec 05, '02 11:56:31AM

One other easy way to try is Command+Option+Escape, then hit return. Even if you can't see the Force Quit dialog, I've found the focus on it is usually set correctly, such that just hitting return will quit the mucked-up app.



[ Reply to This | # ]
One more
Authored by: Malleus on Dec 05, '02 02:15:51PM

I have found this works sometimes to, but usually it takes two returns to kill the offending app. One return for selecting, and one to confirm it when the "Are you sure you want to quit, you will lose unsaved changes..." box comes up.



[ Reply to This | # ]
How to kill a Zombie?
Authored by: patrickoehlinger on Dec 05, '02 02:18:55PM
It happend to me that a App (owned by root) stopped in Zombie mode (Process Viewer sad so).
In the Terminal I tried kill PID_of_Zombie_App but OS X complained that it didn't found the PID, I even tried it with sudo. But no chance, I had to restart :-( my system to get ride of the Zombie.


Any idea what I could do next time?

[ Reply to This | # ]

How to kill a Zombie?
Authored by: brandonedling on Dec 05, '02 03:37:52PM

My understanding is that a zombie is like a child process... it's spawned by another running process. I might very well be wrong, though...



[ Reply to This | # ]
How to kill a Zombie?
Authored by: a1291762 on Dec 05, '02 05:05:07PM

Zombies are generally caused by bad programming :)

I think that a restart is the only way to get rid of them.

They turned up a lot on the Unix machine at Uni where all the C students were writing code :)



[ Reply to This | # ]
How to kill a Zombie?
Authored by: babbage on Dec 06, '02 05:42:40PM

I forget the exact definition at the moment, but basically a zombie process is one that is stuck in a situation where it is waiting for some kind of system event or input. So for example if you have a login shell and kill the window, maybe your shell process could end up being a zombie if it's waiting for user input that will never come.

The bad thing is that, as another commenter noted, these are usually the result of shoddy programming, & because the zombie is waiting for some specific event [which will never occur at this point] you can't kill it because the program is blocked on waiting for that other input. Bummer.

On the other hand, a program in this state consumes almost no system resources, so it's not that bad. They consume almost no ram, by definition they consume no CPU time, etc. So yeah, if you want to kill them off you have to reboot, but they're more annoying than harmful -- if you want you can just leave them around until the next time you would have had to reboot anyway.



[ Reply to This | # ]
How to kill a Zombie?
Authored by: sjmadsen on Dec 07, '02 02:11:27PM
This page gives an explanation of a zombie process. In a nutshell, a zombie is a child process whose parent hasn't come along to pick up its exit code. The zombie only consumes an entry in the process table; it doesn't use up any memory or other system resources and does not use any CPU. When the parent exits, the zombies should go away as well, but if not, a reboot is the only way to clean them up. The previous posters are correct that zombies are caused by poor programming, but to say the processes are waiting on an event is not quite right.

[ Reply to This | # ]
How to kill a Zombie?
Authored by: Lanir on Dec 14, '02 06:28:47AM
I don't have a zombie process to try this on. But... here's the deal. Kill has several flags you can use. I just explained this earlier, but just in case... The most commonly useful of these are like so:

kill -HUP # Used to hangup. Does not necessarily stop the program from
# running. Very useful to tell a daemon process to look at
# it's config file again.

kill # No flags. Just tells it to clean up it's stuff and leave.
# Analogous to an eviction notice.

kill -KILL # Tells the system to actively kill it, not just politely
# tell it to leave. Analogous to the eviction notice above,
# combined with "... and I'll be back in a minute with my
# shotgun so you better be gone!"

kill 1 # Go into single user mode without rebooting. The system
# should start up again right after you type exit in
# the shell. Basically keeps the system stuff intact while
# cleaning house on all user processes. Should disable
# networking as well but I haven't checked.

[ Reply to This | # ]
10.2 loves its beachballs
Authored by: mimpergint on Dec 08, '02 05:45:52AM

Some people claim their Jaguars can run for weeks without crashing. Mine does so nearly daily. MS Explorer especially has a bad habit of going into beachball mode and not coming out of it. Usually the force quit command doesn't work in these cases, so I head to the terminal and 'kill PID' . Does this have further destabilizing effects upon the system? I ask this because usually within a few minutes none of my applications, including the finder, responds. I should add that (at least in yesterdays case) before the whole system disappeared into the swamp I tried reloading IE, which never made it, but went beachballing right away. This is really frustrating, and I can't understand why my supposedly ultra-stable iMac (g4) is behaving so poorly. Any ideas?



[ Reply to This | # ]
Re: 10.2 loves its beachballs
Authored by: ibjmn144 on Dec 08, '02 12:09:45PM

Your problem is that you're using Explorer. Try using a different browser like OmniWeb (my favorite) or Chimera. I have had similar experiences with OS X but the problem is always the program, not the OS.

As a sidenote, you'll have better experiences if you keep away from our favorite monopoly. ;)



[ Reply to This | # ]