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

20060105: 20060104: 20060104: CGI image generation with gpnexr2

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.

  • Subject: 20060105: 20060104: 20060104: CGI image generation with gpnexr2
  • Date: Thu, 05 Jan 2006 12:18:54 -0700
Ben,

The message queues owned by both ldm and www are likely doe to failures in
the script.

As both those users, I'd suggest running the "cleanup -c" command from
the GEMPAK script directory to remove the message queues and kill any lingering 
gplt processes.
You should also check to make sure there aren't any "gif" processes as well.

Steve Chiswell
Unidata User Support



>From: Ben Cotton <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200601051838.k05Ics7s013035

>On Thu, 5 Jan 2006, Unidata Support wrote:
>
>> I don't see what version of GEMPAK you are running, but probably
>> not the laet 2 distributions which gpnexr2_gif would have been installed.
>> Otherwise, it could be built from the source tree if you have a source distr
> ibution by:
>> cd $NAWIPS/unidata/programs/gpnexr2
>> make all
>> make programs_gf
>> make clean
>>
>Looks like 5.8.3.  Someone decided that our GEMPAK directory should be 
>owned by root instead of being in a place where I could access it, so I'll 
>have to get the desktop computing support people to update the GEMPAK 
>build.
>
>> Also, you are hardcoding a bunch of envirionmental variables into your
>> csh instead of sourcing a Gemenviron file, so your script will definitely
>> have to be updated for $GEMEXE in 5.8.4 and later since GEMEXE is
>> now $NAWIPS/os/$NA_OS/bin.
>>
>Yeah, there was a reason I did it that way when I was working on it last 
>night, although what that reason may be has now escaped me.  The final 
>version will source a Gemenviron file.
>
>> If the script had been run by hand, check the radar.tmp file permissions to
>> make sure that the script web user can overwrite it.
>>
>The radar.tmp file is 777.  I was able to delete it as 'bcotton' (it was 
>owned by 'ldm').
>
>> Does the "ipcs" command show anything?
>>
>------ Message Queues --------
>key        msqid      owner      perms      used-bytes   messages
>0x00001961 1042251776 ldm        600        0            0
>0x00bcb162 939360262  www        666        0            0
>0x00bc9379 936968199  www        666        0            0
>0x02b926ed 937033738  www        666        0            0
>0x00bca844 938409995  www        666        0            0
>0x02b93bb1 938475532  www        666        0            0
>0x00bcb9cf 939720717  www        666        12           1
>0x02b944ba 939425806  www        666        0            0
>0x00bc53f1 941195279  www        666        12           1
>
>
>Thanks,
>Ben
>
>==================
>Ben Cotton, KC9FYX
>LDM Administrator
>Dept of Earth & Atmos. Sci.
>Purdue University
>
>http://www.funnelfiasco.com
>
>O: (765) 49-40655
>C: (765) 586-8992
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.