Hi,
My initial posting detailed a problem with IPX consoles becoming unusable when
users exit OpenWindows or X11R4. Thanks to everyone who responded. I managed
to get the workstation working again without a reboot.
Many thanks to ...
marquard@astrosun.TN.CORNELL.EDU (Jan M. Sys Admin) Jan Marquardt
vasey@issi.com (Ron Vasey)
Mark Ferraretto <mferrare@physics.adelaide.edu.au>
Kevin Elphinstone <kevine@vast.unsw.edu.au>
John Posey <posey@utdallas.edu>
stephen@node49.medtronic.COM (Stephen Dowdy)
birger@vest.sdata.no ( Birger Wathne)
Steve Lodin <swlodin@kocrsv01.delcoelect.com>
Steve Swaney <steve@fsg.com>
dpeterso@sirius.UVic.CA (Dave Peterson)
Perry_Hutchison.Portland@xerox.com
rjq@phys.ksu.edu (Rob Quinn)
bmskc!moe!sisul@uunet.uu.net (Jim Sisul)
keener@upenn5.hep.upenn.edu (Paul T. Keener)
The solutions were wide and varied, I tried the simplest first. It worked.
Your mileage may vary ...
In essence the solutions were as follows
1) Enter ^Q (i.e. control/Q).
I had my doubts, but, at least this time, it worked!
Ok, its the first thing I'd try on a `stuck' ANSI terminal.
How the console got into this state is however a mystery - the last
keyboard interaction was clicking the "exit" button ...
2) kbd_mode -a from a remote login
This is useful if you terminate your window session abnormally. It resets
the console keyboard to ASCII. See kb(4s) for more info.
I recommend to my users that they invoke X11 (or openwindows) with an alias
like
/usr/local/X11R5/bin/xinit; /usr/local/X11R5/bin/kbd_mode -a; /bin/clear_colormap
3) reset
resets the console tty parameters
this of course will need to be run from the console, so someone suggested
including this in the .logout (running setuid root). I'm not sure of the
advantages of having this run as root.
I'd change the system call to read system("/usr/ucb/reset") to ensure you
don't call someone elses "reset" program as root.
4) starting an X session from a remote host (output directed to the problem
machine).
I tried this, and while x windows DID work, the console went dead again
after I quit. This does work sometimes though not this time.
5) look for any `console grabbing' commands e.g. xterm -C, cmdtool -C etc.
Programmes can be disabled from redirecting console i/o with kernel patch
100188-01, but I guess that this will have little effect since xterm is
usually installed setuid root.
6) write a c program to direct console i/o back to the console.
anyone done this?
7) startup and quit sunview
8) Try L1-a, c(ontinue) or go.
This didn't work for me, probably because I couldn't see what I was typing
...
9) reboot
The last resort ...
All the above methods have had some degree of success for someone. Although the
simplest solution worked this time (thanks Jan!).
Thanks again for everyone's prompt advice. I'd be interested in hearing from
anyone out there who has similar problems, and what success they have with the
above advice.
Responses included below ...
--------------------------------------------------------------------------------
Date: Thu, 26 Mar 92 14:39:54 EST
From: marquard@astrosun.TN.CORNELL.EDU (Jan M. Sys Admin)
Hi,
Have you tried ^Q to clear the problem? Seems a bit strange, but
all the symptoms you give are of a suspended screen.
- Jan Marquardt
--------------------------------------------------------------------------------
From: vasey@issi.com (Ron Vasey)
Date: Thu, 26 Mar 92 13:39:01 CDT
Strange ... kbd_mode -a has always worked for me, even via remote login.
Depending on how your environment is organized, it's best to put it either
at the end of .xinitrc, or start X like "xinit; kbd_mode -a" (aliased).
Either method should ensure the keyboard will be reset after <SomeX> quits.
--------------------------------------------------------------------------------
From: Mark Ferraretto <mferrare@physics.adelaide.edu.au>
We've had this problem here too. It's caused by users not exiting X properly
(ie they log onto another terminal and kill -9 X:0) or starting 2 X processes
on top of each other.
The way I get rid of this is kill all the user's processes from a remote
terminal. I then setenv DISPLAY workstation:0 and start X on it from the
remote terminal. I then exit that X session from the console and everything
sorts itself out. This is something I've also gotten the users to do
themselves.
--------------------------------------------------------------------------------
Date: Fri, 27 Mar 92 13:51:23 +1000
From: Kevin Elphinstone <kevine@vast.unsw.edu.au>
kbd_mode -a
from the MIT X distribution should restore the keyboard. You obviously
have to rlogin from another machine to run it.
--------------------------------------------------------------------------------
From: John Posey <posey@utdallas.edu>
Date: Thu, 26 Mar 1992 21:53:59 -0600
I have seen this on SS2s and SS1+s. I can occasionally get the console
to come back by:
1) kill any user processes associated with the console
2) kill the getty on /dev/console
3) kill -1 1
4) sync;sync;sync;sync
5) L1-a
6) issuing a non destructive command like ?
7) "c" or "go" depending on the boot prom prompt.
Note that this only sometimes works. Also, it sometimes doesn't work
right away... I will do the above and not get access to the keyboard,
but I will an hour later (!?!).
The machines I have this problem with are being used as servers, so leaving
the keyboard unusable is not normally a problem.
--------------------------------------------------------------------------------
Date: Thu, 26 Mar 92 21:45:45 MST
From: stephen@node49.medtronic.COM (Stephen Dowdy)
Just in case you haven't checked this....
If there is an 'xterm -C' or '{cmd,shell}tool -C' running anywhere, then
that has trapped the console. KILL IT!. Anyone remote logging on that
system that starts an xterm,cmd or shelltool with the -C will steal the
console. The man page on the console describes this 'bug/misfeature' in
that anyone calling the ioctl to nab /dev/console may do so, since there
is no check to determine if the 'nab'-er is the "owner". You could try
writing a quickie program to call this ioctl value and attempt to restore
the console.
Do a 'ps' to make sure that no processes are hanging around that may
be blocking console access. I *have* had a few instances, though, where
reboots were necessary to recover the console
--------------------------------------------------------------------------------
Date: Fri, 27 Mar 92 08:06:54 +0100
From: birger@vest.sdata.no ( Birger Wathne)
Could be some other user starting a console window.
If a user with display on host a (or X-terminal a) starts a console
window on host b (xterm -C, cmdtool -C, contool, etc), host b's console
will be "dead" until the app quits.
The X server already running will be fine, but as soon as the user running
X on host b quits, the console will be unusable until the
user on host a lets go of the console.
You can either force users not to start console windows on remote hosts,
or install a Sun patch for the problem. This patch will not stop
xterm -C if xterm is a suid-program (it is at many sites).
--------------------------------------------------------------------------------
Date: Fri, 27 Mar 92 07:23:49 EST
From: Steve Lodin <swlodin@kocrsv01.delcoelect.com>
I just had it happen once on a SS2. I had a user who normally runs X11R4
try to switch over to OW3. One time he logged out and the exact same thing
happened. The only thing I could do was reboot. Oh, his screen went white.
I essentially ignored the problem, and it hasn`t happened since.
--------------------------------------------------------------------------------
Date: Fri, 27 Mar 92 08:51:48 EST
From: steve@buick
Looks like someone has remotely grabbed the console from the machine
which won't run the console by:
rsh <machine_without_console> xterm -C -display <remote_machine>
I seem to remember a fix to prevent this from happening. (potential
security problem), but i can't remember where I saw it.
--------------------------------------------------------------------------------
Date: Fri, 27 Mar 92 11:22:14 PST
From: dpeterso@sirius.UVic.CA (Dave Peterson)
The console problem you describe in your posting of March 26 sounds very
much like one we have. Unfortunately, no one has been able to solve it for
us! We are running Xwindows on an IPX, and whenever someone activates
our Parcplace Smalltalk development system from the window manager, exits
Smalltalk, and exits the window manager, we end up with a dead console (no
Unix prompt, no response to keyboard, no response to killing all processes
associated with the console, etc.). We have to reboot every time. However, background processes and rlogins function normally. Furthermore, the window
manager appears to work normally after exiting Smalltalk.
The only clue I have noticed is that after exiting Smalltalk and exiting
the window manager, there is an active root process `rpc.rstatd' that should
not be alive. This process starts up when the window manager is activated and
is normally deactivated upon exiting the window manager. Unfortunately I am
not a UNIX pro, and don't know if this is relevant. I am still trying to flag
down our overworked system administrator.
In any case, can you keep me posted on your problem? If we solve ours, I'll
let you know.
--------------------------------------------------------------------------------
Date: Fri, 27 Mar 1992 12:53:44 PST
From: Perry_Hutchison.Portland@xerox.com
Perhaps someone has specified -C to an xterm, which has dutifully
redirected the console to its pty. Then for some reason the xterm
fails to cancel the redirection before exiting. This would arguably be
an X11 and/or OpenWindows bug, since they should cancel any console
redirections when exiting.
A possible workaround would be to write a program to issue the
appropriate system call to cancel console redirection. It's probably
something like an ioctl to /dev/console. One way to at least get into
the right part of the manual might be to look at the code for xterm,
and see what it does when it gets a -C switch.
--------------------------------------------------------------------------------
Date: Fri, 27 Mar 92 21:38:37 CST
From: rjq@phys.ksu.edu (Rob Quinn)
Is the Num-Lock led left on? I have that at times. The cure seems to be
to start sunview. When it exits, the keyboard is okay.
--------------------------------------------------------------------------------
Date: Fri, 27 Mar 92 10:00:41 CST
From: bmskc!moe!sisul@uunet.uu.net (Jim Sisul)
I am currently grapling with a similar problem in our SPARCstation 2s.
It seems that after closing OpenWindows and logging out, the login console
requires that every key be typed exactly twice before it will display. The
hidden password, however, need only be typed as-is. If the user makes a
mistake logging in (which is likely given how messed up the console is),
the console resets itself to normal.
I called Sun's local office here in Kansas City, and they reccommended using
the reset command. (The manual page is reset(1))
If you can rlogin to the offending machine, try executing reset as root.
I wrote a C program that calls system("reset"), and put it in everyone's
.logout file. I made a binary program and not just a call to reset
so the program can set its user ID to root when it executes (chmod +s).
Like you, my problem is sporadic. I've never seen it myself, I just get
complaints from users. I haven't heard any gripes since putting the
root-running call to reset in everyone's .logout file, but that's hardly
proof. I hope this is of some help. The program follows. Just remember
to change its ownership to root and turn on the set user id on execution bit
with chmod +s, and then make it the last call in everyone's .logout file.
---------------------------------
void main(argc, argv)
int argc ;
char *argv[] ;
{
int dummy;
dummy = system("reset");
}
---------------------------------
--------------------------------------------------------------------------------
Date: Sun, 29 Mar 92 20:40:56 EST
From: keener@upenn5.hep.upenn.edu (Paul T. Keener)
I have had similar problems. One workaround that I have found is to unplug
that keyboard cable and plug it back it. This will reset the driver and
drop you into PROM mode. Simply type "c" for continue and you will be back
up.
As for a real solution I am not sure. I have tried reseting the keyboard
driver with the KIOCCMD ioctl (function KBD_CMD_RESET) and got an error
(unfortunately I do not remember what the error was). It seems to me that the
kbd driver either is getting hosed or isn't being pushed back on the stream
properly, or something like that. I think the next time I see it, I will
try to push a new driver on and see what happens.
--------------------------------------------------------------------------------
And finally, my original question ...
--------------------------------------------------------------------------------
Hi,
We have a number of Sun workstations, a mixture of SPARCstation 1's, 1+'s,
IPCs, SLCs, ELCs and IPXs. A problem that occurs infrequently is that when
users quit X11 (R4) or Open Windows (2.0) the console no longer works. All
keyboard input is ignored (even L1-a). Output sent to the console is also lost
(e.g. using cat > /dev/console). All other functions continue as usual -
rlogins, background jobs etc all continue to work normally. So far, the only
way I've been able to revive the console is by a reboot. Because the problem is
intermittent, it might be hours, days, weeks or months between occurences.
Has anyone else experienced this problem? It seems to be confined to the IPX's,
but I can't be sure of this. Is there any way to revive the console? I've
tried
getting rid of all user processes associated with the console
killing and restarting the getty on /dev/console
restarting init (kill -1 1)
kbd_mode -a
clear_colormap
None of which seem to make a difference.
Thanks in advance for any helpful advice.
-- David Beard Phone: (+61 8) 228 5709 Computer Systems Manager FAX: (+61 8) 232 5670 Departments of Statistics, Pure & Applied Mathematics University of Adelaide South Australia E-mail: beard@maths.adelaide.edu.au
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:40 CDT