Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!hp4nl!fwi.uva.nl!casper
From: casper@fwi.uva.nl (Casper H.S. Dik)
Newsgroups: comp.windows.x
Subject: Re: Sun console problem
Message-ID: <1991Feb22.235705.27208@fwi.uva.nl>
Date: 22 Feb 91 23:57:05 GMT
References: <9102221205.AA01177@lightning.McRCIM.McGill.EDU>
Sender: news@fwi.uva.nl
Organization: FWI, University of Amsterdam
Lines: 31
Nntp-Posting-Host: zoe.fwi.uva.nl

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