Subject: Re: DGL refuses connection from SPARCStation
Keywords: DGL Sun
Message-ID: <pk5pcrk@fido.asd.sgi.com>
Date: 9 Sep 92 02:56:24 GMT
References: <myers.715552750@haydn>
Sender: news@fido.asd.sgi.com (Usenet News Admin)
Organization: Silicon Graphics, Inc.
Lines: 51
>We recently ran into a perplexing problem after I upgraded our
>4D/30 to 4.0.1.
>
>A user on a SPARCStation 2 had previously been able to do a remote
>shell to the SGI to run some graphics programs. Now his TCP connection
>is refused. The error can be replicated by trying to a "rsh blanktime 0"
>from the command line. The most interesting part of this problem is that
>the command CAN be executed from another SGI machine. It seems to be a
>Sun/SGI problem. (Yes, both the Sun and the second SGI are in the .rhosts
>file). Rsh's to do such things as execute the date command work fine.
>
>From Sun(bette) to SGI(kate):
>
> %rsh kate blanktime 0
> (long pause)
> %dgl error (TCP connect): Connection refused
> %dgl error (default init): default dglopen(brackett@bette,4) returned -127
>
>From SGI(hermes)to SGI(kate):
>
> %rsh kate blanktime 0
> %
My guess is that the SGI is trying to display a GL program (blanktime) on a non-SGI
machine (the Sun), causing the DGL error. (In this case, blanktime doesn't really
display anything, but it uses GL to affect a screen. The same idea applies to GL
programs that actually do display graphics.) This would happen if, in your remote shell on kate, either of the environment variables DISPLAY or REMOTEHOST pointed at
bette rather than kate. Do this to make sure that neither of them points to bette:
%rsh kate
kate% printenv DISPLAY
kate% printenv REMOTEHOST
I'd guess that DISPLAY is not being set to anything, and that REMOTEHOST points to
bette. When DISPLAY is not set, the GL sees if REMOTEHOST is set and uses that as the
host to display to. You can put a hack such as this in your .login on kate to make
sure DISPLAY points to kate when you are logging in from bette:
if ($?DISPLAY == 0 && $REMOTEHOST == "bette") then
setenv DISPLAY ":0"
endif
There are probably more creative and cleaner solutions to this problem, but this is
all I've come up with right now.
You ran into this problem while upgrading to 4.0.1 because, as of 4.0, the GL gained
the ability to display on remote machines. Before, the GL always displayed to the
local machine, so you never had a problem with blanktime trying to display on the Sun.