steven@uhunix.uhcc.Hawaii.Edu (Steven Sakata) (07/05/90)
We've just installed X11/R4 on our Suns (SPARCstations and Sun 490s) compiled under SunOS 4.0.3 and we have the following problem: If someone starts up X, using xinit, .xinitrc, xterm, twm, etc., and then kills the server process X:0, the console is left in a hung state. The system is still up (I can telnet, ftp, etc to it), but I can no longer use the console. The only way I can get the console back is by performing a shutdown and reboot. Does anyone out there know of a solution to this so I don't have to keep shut- ting down the system. Any advice would be appreciated. Thanks, Steven. ps. I try to inform as the users to not kill the X:0 process, but these systems are in a workstation lab at a university where many different users come and go. ------------------------------------------------------------------------------- Steven Sakata (University of Hawaii Computing Center) Internet: steven@uhunix.uhcc.Hawaii.Edu Bitnet: steven@uhunix.bitnet
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (07/05/90)
> We've just installed X11/R4 on our Suns (SPARCstations and Sun 490s) > compiled under SunOS 4.0.3 and we have the following problem: > If someone starts up X, using xinit, .xinitrc, xterm, twm, etc., and > then kills the server process X:0, the console is left in a hung > state. The system is still up (I can telnet, ftp, etc to it), but I > can no longer use the console. The only way I can get the console > back is by performing a shutdown and reboot. You'll probably find this is not the only way. Try running "kbd_mode -a" (kbd_mode is in the mit/server/ddx/sun directory and is installed as part of a "make install"). If the server is being killed with SIGTERM (eg, kill with no signal specified on the command line), this is a bug: Xsun is supposed to reset the keyboard state when it gets a SIGTERM. If kill -KILL (aka kill -9) is being used, well, if users insist in shooting themselves in the foot they shouldn't be surprised when it hurts. > ps. I try to inform as the users to not kill the X:0 process, but > these systems are in a workstation lab at a university where many > different users come and go. Users who randomly kill processes without understanding what they're doing deserve to lose. (The problem is that they also take one X station out of service until some support type can fix it.) You might consider hacking xinit so it runs the equivalent of kbd_mode -a if the server dies unexpectedly; this may be the cleanest solution for your lab. (kbd_mode is not complicated; UTSL. It's basically a tiny wrapper around KIOCTRANS.) You might also consider setting the machines up with xdm, so that Xsun is always running as root, so vanilla users can't kill it. (If you have people using SunView[%], this isn't a solution for you.) [%] Or whatever they're calling the current version of it this week. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mike@raven.uss.tek.com (Mike Ewan) (07/07/90)
In article <8514@uhccux.uhcc.Hawaii.Edu> steven@uhunix.uhcc.Hawaii.Edu (Steven Sakata) writes: > >However, I've tried that, and it still doesn't free the console. I've telneted >over to the system that has the hung console, and I ran that command, and it >doesn't seem to do anything. Any ideas?.....Thanks, Steven. I've seen the same thing on a VAXstationII and R4, except it was when I was closing out X. The man page for xinit says that it waits for .xinitrc to exit then kills the server. Well, it appears that it is waiting forever for something instead of killing the server. I have to rlogin from some other machine, kill off everything related to X, kill my console login and kick the getty to get back the console. Mike -- Michael Ewan (503)627-6468 Internet: mike@raven.USS.TEK.COM Unix Systems Support UUCP: ...!tektronix!puffin!raven!mike Tektronix, Inc. Compuserve: 73747,2304 "Fig Newton: The force required to accelerate a fig 39.37 inches/sec."--J. Hart