david@phys.anu.edu.au (David Baldwin) (02/18/91)
I am having a problem with people running X clients off SparcStations onto X-terminals (Sun 3/50s). The problem is that sometimes the console locks up and it cannot be used to log in or whatever. From a remote terminal I can start X on the console, or blank it using clear_colormap, but I can't get the getty running on it again. There IS a getty process, but it won't talk to the physical console. I think it is something to do with xterm -C which redirects console output to the pty of the xterm, but how can I switch it back again? The only solution so far is to reboot the *@!* thing every time it happens. I have tried to make every users .xinitrc to only use 'xterm -C' if `tty` = '/dev/console', but some are still getting through. I need some utility that will redirect console output back to the physical console, or else some way of stopping people redirecting it in the first place! Thanks in advance, David. -- ================================================================================ = David Baldwin Internet: david@phys.anu.edu.au Head, School Computer Unit, Phone: (intl) +61+6+2490104 Research School of Physical Sciences, (Australia) (06) 249 0104 Australian National University FAX: (intl) +61+6+2491884 Canberra, ACT, Australia (Australia) (06) 249 1884 ================================================================================ =
mouse@lightning.mcrcim.mcgill.EDU (02/22/91)
> I am having a problem with people running X clients off SparcStations > onto X-terminals (Sun 3/50s). The problem is that sometimes the > console locks up and it cannot be used to log in or whatever. From a > remote terminal I can start X on the console, or blank it using > clear_colormap, but I can't get the getty running on it again. There > IS a getty process, but it won't talk to the physical console. I > think it is something to do with xterm -C which redirects console > output to the pty of the xterm, but how can I switch it back again? Convince xterm to close the pty. The easiest way to do this is to kill xterm. (Any xterm -C running on *our* servers gets blown away as soon as I notice it. We don't take kindly to users stealing the consoles away.) > I need some utility that will redirect console output back to the > physical console, You can do this by writing a program which grabs a pty, does TIOCCONS on it, and immediately closes it. This works because the kernel doesn't remember that you grabbed the console away from another pty instead of from the real console, so when you close the pty it reverts back to the real console. I don't have such a program; I've never needed it. > or else some way of stopping people redirecting it in the first > place! IMO there should be a kernel variable (ie, patchable with adb) to control whether TIOCCONS works or not. If 4.1.1 (which we will be installing soon, I hope) doesn't have something of the sort, I'll probably take a dive into the kernel myself and try to create a patch which will just disable TIOCCONS altogether.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
pwh@bradley.bradley.edu (Pete Hartman) (02/23/91)
In <9102221205.AA01177@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU writes: >> I am having a problem with people running X clients off SparcStations >> onto X-terminals (Sun 3/50s). The problem is that sometimes the >> console locks up and it cannot be used to log in or whatever. From a >> remote terminal I can start X on the console, or blank it using >> clear_colormap, but I can't get the getty running on it again. There >> IS a getty process, but it won't talk to the physical console. I >> think it is something to do with xterm -C which redirects console >> output to the pty of the xterm, but how can I switch it back again? >Convince xterm to close the pty. The easiest way to do this is to kill >xterm. (Any xterm -C running on *our* servers gets blown away as soon >as I notice it. We don't take kindly to users stealing the consoles >away.) Is this a problem with xterms running on the console itself as well? I've had problems running X on our 4/470 console when it would die in a non-standard way (i.e. X crash, like running aquarium with a million things to see how hard we could abuse it), and had to reboot the machine to get the getty to work again. I guess what I'm asking is there any other way (besides xterm -C) for X to hose up the getty on the console? -- ----- Pete Hartman Bradley University pwh@bradley.bradley.edu One final word to the young people who listen to this record. Be cool. The retina of the eye quivers to the dance of soundwaves. Turn on. Tune in.
casper@fwi.uva.nl (Casper H.S. Dik) (02/23/91)
mouse@lightning.mcrcim.mcgill.EDU writes: >> I am having a problem with people running X clients off SparcStations >> onto X-terminals (Sun 3/50s). The problem is that sometimes the >> console locks up and it cannot be used to log in or whatever. From a >> remote terminal I can start X on the console, or blank it using >> clear_colormap, but I can't get the getty running on it again. There >> IS a getty process, but it won't talk to the physical console. I >> think it is something to do with xterm -C which redirects console >> output to the pty of the xterm, but how can I switch it back again? >Convince xterm to close the pty. The easiest way to do this is to kill >xterm. (Any xterm -C running on *our* servers gets blown away as soon >as I notice it. We don't take kindly to users stealing the consoles >away.) There are actually to ways to solve the TIOCCONS problem. Get the patch that disable TIOCCONS people not permited to read/write from/to /dev/console, or create /dev/console as major 1, minor 0. (Normally this is (0,0)) I haven't really tried the last one, but the /dev/con (1,0) I created, could not be redirected with TIOCCONS. I haven't tried booting the system with (1,0) as /dev/console. That is only advisable on systems without a frame buffer. Casper -- NOTE: Some machine instructions | Casper H.S. Dik must be executed on the CPU. | casper@fwi.uva.nl (a manual page on the Gould PowerNode) | NIC: !cd151