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

20050509: 20050509: 20050507: nex2gini seg faults in Solaris 9/10

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: 20050509: 20050509: 20050507: nex2gini seg faults in Solaris 9/10
  • Date: Mon, 09 May 2005 16:05:43 -0600
Robert:

The template not found message means that the program did not find the template 
in your
datatype.tbl file. It is in the release as provided by me, so unless you are 
maintaining
 a separate file, it should be there, unless there is a type in the file.

The default for the program is to use the $RAD/NIDS/%SITE%/%PROD% attempt if
a NEXRIII entery isn't provided in the template file.

Feeding from more than one upstream isn't a problem if both machines are 
providing the
exact same MD5 checksum for a product. If however, one of the sources generated 
a different
product by missing a part of the data on ingest, then the MD5 checksum would be 
different. 
Even worse, if your ingest system allowed bad products that had missing parts 
in the product 
(each NOAAPORT product is 4000 bytes max in a segment, so a N0R product could 
have
8 or more pieces that have to be received by your receiver) to be sent as a 
product
anyhow, the display program would definitely fail. Certainly, there is a 
greater chance in
finding that bad product by nex2gini than a user running an NMAP2 loop, since 
nex2gini will
likely be looking at every site that is in the desired region- as opposed to a 
loop
of your local station in NMAP2 (the chances would be about 154 times greater).

When you look at a volume plot of NEXRAD data from a site receiving data from 
numerous
ingestion sites:

http://my.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?NNEXRAD+emo.unidata.ucar.edu

you will see it is smooth, and should look the same as a single ingest site:

http://my.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?NNEXRAD+jackie.unidata.ucar.edu

If you were receiving more bytes than a single source site, that would signal 
an ingest problem.

But, befor going too far down, if you can identify a site/product that is bad, 
I can
give you the number of bytes that the product should have been on ingestion (or 
roughly
what you should be seeing in your disk file. If there is a discrepancy, it 
might be the
cause of errors you are seeing.

Steve Chiswell
Unidata User Support



>From: "Robert Mullenax" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200505091942.j49Jg6P3003473

>This is a multi-part message in MIME format.
>
>------_=_NextPart_001_01C554CF.2B4BE013
>Content-Type: text/plain;
>       charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>Steve,=20
>
>Thanks for the scoop on the compilers.  I will play around with -O2, =
>etc.
>
>I am using -close in my pqact for NIDS data.  As far as receiving it =
>twice, I have both my PDI ingestors set as primary for redundancy.  It =
>is unclear to me if that means I am getting the data twice.  It does =
>appear there is something fishy with my files since it fails 80% of the =
>time with the Unidata binary as well.
>
>I just ran it again, and it works this time.  Once thing I noticed that =
>is odd is this message:
>
>GEMPAK-NEX2GINI>r
> [NEX2GINI 2]  NEXRIII template not found using $RAD/NIDS/%SITE%/%PROD%
> [NEX2GINI 0]  Using:   $RAD/NIDS/TLX/N0R/N0R_20050509_1929
> [NEX2GINI 0]  Using:   $RAD/NIDS/AMA/N0R/N0R_20050509_1931
> [NEX2GINI 0]  Using:   $RAD/NIDS/HGX/N0R/N0R_20050509_1936
>
>However, if I cd to $RAD/NIDS/%SITE%/%PROD% then I do see data.
>
>Any idea, what that means?
>
>Thanks for you help.
>
>Robert Mullenax
>
>
>
>
>
>-
>
>------_=_NextPart_001_01C554CF.2B4BE013
>Content-Type: text/html;
>       charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
><HTML>
><HEAD>
><META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
>charset=3Diso-8859-1">
><META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
>6.5.7226.0">
><TITLE>RE: 20050509: 20050507: nex2gini seg faults in Solaris 9/10 =
></TITLE>
></HEAD>
><BODY>
><!-- Converted from text/plain format -->
>
><P><FONT SIZE=3D2>Steve,<BR>
><BR>
>Thanks for the scoop on the compilers.&nbsp; I will play around with =
>-O2, etc.<BR>
><BR>
>I am using -close in my pqact for NIDS data.&nbsp; As far as receiving =
>it twice, I have both my PDI ingestors set as primary for =
>redundancy.&nbsp; It is unclear to me if that means I am getting the =
>data twice.&nbsp; It does appear there is something fishy with my files =
>since it fails 80% of the time with the Unidata binary as well.<BR>
><BR>
>I just ran it again, and it works this time.&nbsp; Once thing I noticed =
>that is odd is this message:<BR>
><BR>
>GEMPAK-NEX2GINI&gt;r<BR>
>&nbsp;[NEX2GINI 2]&nbsp; NEXRIII template not found using =
>$RAD/NIDS/%SITE%/%PROD%<BR>
>&nbsp;[NEX2GINI 0]&nbsp; Using:&nbsp;&nbsp; =
>$RAD/NIDS/TLX/N0R/N0R_20050509_1929<BR>
>&nbsp;[NEX2GINI 0]&nbsp; Using:&nbsp;&nbsp; =
>$RAD/NIDS/AMA/N0R/N0R_20050509_1931<BR>
>&nbsp;[NEX2GINI 0]&nbsp; Using:&nbsp;&nbsp; =
>$RAD/NIDS/HGX/N0R/N0R_20050509_1936<BR>
><BR>
>However, if I cd to $RAD/NIDS/%SITE%/%PROD% then I do see data.<BR>
><BR>
>Any idea, what that means?<BR>
><BR>
>Thanks for you help.<BR>
><BR>
>Robert Mullenax<BR>
><BR>
><BR>
><BR>
><BR>
><BR>
>-</FONT>
></P>
>
></BODY>
></HTML>
>------_=_NextPart_001_01C554CF.2B4BE013--
>
--
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.