This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Phil, The X server uses authentication to allow users to connect to the console. If a user other than the user who is logged on to the console wishes to connect to the DISPLAY, then the user who owns the console must allow the connection using "xhost + `hostname`". Without being allowed, the connection will be refused. The console is generally your :0.0 server. If you are planning on having the LDM or cron generate products, even when not logged in to the console, then the best solution is to create a virtual fram buffer (the command Xvfb) to allow the automated processes to connect to a :1.0 display without interfering with the console user. The alternative is to use the GIF device driver instead of the GF device driver. The GIF renders in memory rather than to an X server so a connection is not required. However, the fonts allowed by GIF are software only. Steve Chiswell Unidata User Support > Steve- > > Currently, we have our gempak cron process our NEXRAD imagery every > 10 minutes -- certainly not the best way to do it. I have tried to > use the EXEC function from the LDM but have run into a problem. I am > trying to run a script called nexrad.csh that plots radar data from > GPMAP. It works fine when I pass the script and variables from the > command line when I ssh in as gempak, but when I run it from the LDM I > get the error: > > Xlib: connection to "twister.sbs.ohio-state.edu:0.0" refused by server > Xlib: No protocol specified > > [GEMPLT -83] NDISP - DISPLAY not set or invalid > > When I log into the LDM via Shell, I notice the $DISPLAY variable is > not set... but it shouldn't matter since it's set in the script, > right? I've also tried localhost:0.0 and still have the same problem. > Interestingly, when I log into shell in Gempak and then log into the > LDM via su ldm, the script functions as it should. > > I think I remember us briefly discussing this in the workshop, but I > don't see any details in my notes. Thanks in advance for any help you > may be able to offer. I'll keep looking through the support archives > and let you know if I figure out how to solve the problem. > > > - Phil Birnie > The Ohio State University > Department of Geography > Webmaster > > > > Ticket Details =================== Ticket ID: BQG-799346 Department: Support GEMPAK Priority: Normal Status: Closed