User level program freeze

If a program gets out of hand and freezes up user space, what is a good way for a user to handle that?

With NT, Ctrl+Alt+Del issues a kernel interrupt and can be used to access tools like task manager. Does FreeBSD offer similar facilities?

A bit of background, I was working with a full screen program the other day. The program hung up on me, depriving me of keyboard and mouse input. Fortunately I could switch to a different VT and kill the program remotely. If X itself freezes, am I still able to switch terminals?
 
If X itself freezes you can still switch terminals, but the effectiveness depends on your driver. Control-alt-fx (where x is 1 to 6 or 7). The problem though is the graphics driver. Mine for example renders the console completely unreadable as soon as X is activated, thus making the switch to the console pretty useless.

The facilities for checking processes are basically ps and kill. (edit) There could be some GUI front-ends available but I am not familiar with those myself.
 
DCH3416, an X server normally grabs the input devices pretty hard, so recovering from an X crash on the console can be a challenge. Practically speaking, the most common way to recover from a frozen or otherwise irreparably busted X server, is to log in over the network from another computer using ssh, and send a signal to the X server process (or more often, the sequence of signals: TERM, QUIT and KILL). Once the messed up X server's gone, you can start a new one over the same ssh session (this may seem weird at first, but it works fine).

I've noticed that even if an X server misbehaves in a way that leaves the computer's video hardware in an insane state, if that X server's stopped and a new one's started, the new one will often bring about OK, working video (and console input devices) again, with no reboot required.

And there are times when it won't. There are times when the X server gets the video hardware and/or input devices in to a state that cannot be recovered from without rebooting the computer. Yet if the hardware's chosen with care, it's pretty unusual to see this sort of behavior once the configuration's initially ironed out.

PS. I was slowly fumbling out my reply as ShelLuser commented, and 'seems that our thoughts on this topic match.
 
I just tried and could bind a global shortcut key (Meta-Shift-S in this case) to run System Monitor in KDE. As pointed out above, though, this may or may not work when there's an actual hang of some sort.
Also, Ctrl-Alt-Backspace might be mapped to kill the X server, so these days that mapping may be disabled by default.
 
Also, Ctrl-Alt-Backspace might be mapped to kill the X server, so these days that mapping may be disabled by default.

Good point - often this keystroke is a last resort that helps. If it is disabled, that should be in the xorg.conf file - mine is in /usr/local/lib/X11/xorg.conf:

Code:
    Option      "DontZap" "off"

This double negation should make the key work. (Checking that this works is like checking the parachute before the flight ;) )
 
If X itself freezes you can still switch terminals, but the effectiveness depends on your driver. Control-alt-fx (where x is 1 to 6 or 7). The problem though is the graphics driver. Mine for example renders the console completely unreadable as soon as X is activated, thus making the switch to the console pretty useless.

The facilities for checking processes are basically ps and kill. (edit) There could be some GUI front-ends available but I am not familiar with those myself.

What handles the Ctrl+Alt+Fn shortcuts? Is that system level?
 
the most common way to recover from a frozen or otherwise irreparably busted X server, is to log in over the network from another computer using ssh
BTW, if you don't have another computer around, you may also be able to do this from a mobile device using apps like Prompt (iOS) or JuiceSSH (Android). I've used the former in similar situations on an iPad and it gets the job done.
 
Back
Top