[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GEMPAK #BLQ-341292]: Unidata

> Hi Steve or whoever receives this email.  I hope you don't mind me sending
> you this email directly.  I don't think this is gembud material.
> 
> I was trying to get sfmap_gf script to run from the cron...but couldn't get
> it to output a GIF.  I could run it manually via a terminal command and it
> successfully produced a GIF.  I then replaced sfmap_gf with sfmap.  I
> changed the device from gf to gif and added a gpend to the end.  I ran the
> script manually and it successfully produced a GIF.  I then tried it from
> cron and it successfully produced a GIF.  Initially, it wouldn't run from
> cron.  When I rain it from a terminal using -v, it gave an error message
> (paraphrased) "Fatal error initializing GMPLT"..."too many devices".  So I
> rebooted and then it successfully ran from cron.

When you run from cron, you don't have access to your console X server
(whose magic cookie is unknown to your shell script). 

To use the hardware GF driver (or the _gf linked program version), you must
have contact with the X server and your DISPLAY environmental variable must
be set.

To generate images from cron, typically most sites will run the Xvfb virtual 
frame
buffer daemon which allows you to display to a frame buffer in memory, eg:
/usr/bin/Xvfb :1 -screen 0 1280x1024x24 -shmem 1 &
Thius is easiest done at boot time from your init.d. Your DISPLAY variable would
then be your `hostname`:1.


> 
> I was just wondering why the _gf version wasn't able to run from cron.  I
> personally like the _gf output (hardware) better than the other version
> (software).  I'm guessing that it may have something to do with the
> difference of running GF through X-Server and not running GIF through
> X-Server.
> 
> Side question:
> 
> While I cannot run gdplot2_gf from cron, I do run it manually for some model
> data GIFs.  It takes too long to run using gdplot2.  I was under the
> impression that the GF version does NOT require a gpend.  Is this correct?

The _gf version does not require gpend since the directly lined version
eliminates the use of a message queue. Also, that means you cannot
overlay graphics from other programs since as soon as you exit the program, the
output file is complete. The last 3 distributions have had the U. Albany
contribution of faster message queue connection linked in, so the use of
message queue doesn't have that 1 second delay like older versions.

Again, if you are doing all plotting in a single program, the _gf work great.
If you want to overlay other graphics with gpmap, sfmap, etc, you
will need the message queue to have the other programs talk to the
same display.

Steve Chiswell
Unidata User Support

> 
> Thanks for for your time.
> 
> 
> Brian Koochel
> Meteorologist
> Weather or Not, Inc.
> 
> 
> 


Ticket Details
===================
Ticket ID: BLQ-341292
Department: Support GEMPAK
Priority: Normal
Status: Closed