killing a gui mess

[bryan]

How do you remotely kill a frozen gui and cleanly get back to the login screen?

I'm running Jaguar Server 10.2.1 on an Xserve.

A few days ago, a rogue screensaver refused to go away and wouldn't show the password box. Typing in the password blindly didn't help either. I went to my PowerBook running Jaguar and ssh'd into the Xserve and started issuing the kill command to no avail. Killing the item "screensaver" didn't do anything. Neither did killing other processes like the loginwindow, WindowServer, or SystemUIServer. They just keep popping back with different pid's. After about an hour of trying different things, I gave up and issued 'shutdown -r now'.

Last night, I was running ATTO's horribly buggy config utility for the built-in Ultra 160 SCSI card. When I clicked on the Flash pane of the window, the Xserve pretty much stopped responding to keyboard and mouse input. I could move the mouse, but clicks weren't recognized and Cmd-Opt-Esc didn't do anything either. I went back to my PowerBook and checked 'top' and 'ps -aux' but found nothing that sounded like the ATTO config utility. I killed java, loginwindow, WindowServer, etc. to no avail. Again, I resorted to 'shutdown -r now'.

What am I doing wrong?

Thanks in advance,

Bryan

[Glanz]

Issue a "ps -ax" command in a terminal to see the running processes. In the column on the left each process has a number. Use that number with the kill command, not the name of the app. You can force delete the rogue after the process stops.

If your doing this by SSH, you'll have to delete by an rm -f command. If you are doing it via ftp, you'll have to move the app to an account folder first. And if it's a physical network, there shouldn't be a problem for root or even the admin.

[bryan]

I didn't mention it, but I did use the pid. For example, I issued 'kill 427' to kill loginwindow.app. I thought doing this would force a logout of the current session and send the remote computer back to the login screen, but it just sat there with the same frozen screen. Looking at 'top' or 'ps -aux' again revealed loginwindow running again with a different pid, such as 291.

When I remotely killed screensaver ('kill 4592' or something), I don't think it came back, but it didn't disappear from the Xserve's screen--the frozen screensaver image remained and sometimes I could see my arrow cursor moving above the image.

Any ideas?

[ppmax]

you need to add a few args to the kill command:

so you would type:

kill -HUP <process>

you can read more about kill by typing man kill...

[bryan]

I saw HUP in the kill man page (same as kill -1) and its only description was "hang up". What does "hang up" mean, and how does it compare to the other signals like 2, 3, 6, and 9?

Thanks,

Bryan

[bryan]

I didn't mention it, but I did use the pid. For example, I issued 'kill 427' to kill loginwindow.app. I thought doing this would force a logout of the current session and send the remote computer back to the login screen, but it just sat there with the same frozen screen. Looking at 'top' or 'ps -aux' again revealed loginwindow running again with a different pid, such as 291.

When I remotely killed screensaver ('kill 4592' or something), I don't think it came back, but it didn't disappear from the Xserve's screen--the frozen screensaver image remained and sometimes I could see my arrow cursor moving above the image.

Any ideas?

[Titanium Man]

HUP will restart a process once it's killed. As to how it compares with the other flavors of kill, I won't comment since I haven't used'em. Sometimes I can't find the process I'm looking for unless I use wwax. For example, if I'm looking for iChatAgent:

% ps ax | grep iChatAgent | grep -v grep

I get nothing. To find it, I have to do this:

% ps wwax | grep iChatAgent | grep -v grep
344 ?? Ss 0:03.03 /System/Library/PrivateFrameworks/InstantMessage.framework/iChatAgent.app/Contents/MacOS/iChatAgent

[stetner]

Originally posted by Titanium Man
HUP will restart a process once it's killed. Nope, it will not 're-start' the process.

kill send the process a 'signal'.

In general, if the process does not 'catch' (or ignore) the signal the process will be killed. In a lot of cases, processes are written to 'catch' certain signals. IE most daemons will catch a SIGHUP and re-read their configuration files and continue running (I suppose some might just exec themselves to achieve that, there by re-starting).

But kill just sends the signal, it is up to the process as to what happens then.

There are some signals that are special, -9 (SIGKILL) -19 (SIGSTOP), which cannot be caught or ignored.

man signal
for more info

[Titanium Man]

Thanks for the clarification Stetner, I stand corrected. I thought that the process was restarted because when I use 'kill -HUP' (after changing a config file as in your example), the process has a new PID. But I see now that the HUP part wasn't respawning the process: kill -HUP $(ps ax | grep TextEdit | awk '{print $1}') doesn't restart TextEdit. Sorry for spreading misinformation bryan.

[stetner]

Originally posted by Titanium Man
when I use 'kill -HUP' (after changing a config file as in your example), the process has a new PID. Well if the PID is different then it did restart, but what probably happened was that it did a fork/exec to restart itself.