Re: 20040512: netCDF Decoders - Red Hat Linux - metar2nc errors

NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.

On Wed, 12 May 2004, Unidata Support wrote:


------- Forwarded Message

>To: support-decoders@xxxxxxxxxxxxxxxx
>From: "Tom Baltzer" <tbaltzer@xxxxxxxxxxxxxxxx>
>Subject: netCDF Decoders - Red Hat Linux - metar2nc errors
>Organization: UCAR/Unidata
>Keywords: 200405121544.i4CFibdf017469

Institution: Unidata
Package Version: 3.0.3
Operating System: Red Hat Linux
Hardware Information: AMD Dual 2.6 Gig processors, 1 Gig Memory
Inquiry: Hi Robb,

We're seen occasional metar2nc processes hanging out to dry on the LEAD test 
bed machine.   When the log files are checked the messages indicate problems 
with the output NetCDF file - for example:

[ldm@lead1 surface]$ more metarLog.13430.log
Opening data/pub/decoded/netcdf/surface/04051210_metar.nc with ncid 4
Opening data/pub/decoded/netcdf/surface/04051209_metar.nc with ncid 5
Opening data/pub/decoded/netcdf/surface/04051208_metar.nc with ncid 6
Opening data/pub/decoded/netcdf/surface/04051207_metar.nc with ncid 7
Closing data/pub/decoded/netcdf/surface/04051208_metar.nc with ncid 6, No write 
for > 1200 Sec
Closing data/pub/decoded/netcdf/surface/04051207_metar.nc with ncid 7, No write 
for > 1200 Sec
metar metadata file = 
data/pub/decoded/netcdf/surface/../metadata/surface/metar/04051211_metar.meta
Opening data/pub/decoded/netcdf/surface/04051211_metar.nc with ncid 6
Closing data/pub/decoded/netcdf/surface/04051209_metar.nc with ncid 5, No write 
for > 1200 Sec
Opening data/pub/decoded/netcdf/surface/04051208_metar.nc with ncid 5
Opening data/pub/decoded/netcdf/surface/04051209_metar.nc with ncid 7
ncopen: filename "data/pub/decoded/netcdf/surface/04051011_metar.nc":

Not a netCDF file

Tom,

I've encountered this problem with gribtonc, the actual NetCDF file was
not created because there wasn't any space on the disk. Then the decoder
tries to write to the file which causes the following errors. Did you
actually look at 04051011_metar.nc file, is it corrupt?  What machine are
you working on now?

Robb...


ncdimid: ncid -1: Not a netCDF id
ncdiminq: ncid -1: Not a netCDF id
Opening data/pub/decoded/netcdf/surface/04051011_metar.nc with ncid -1
ncrecinq: ncid -1: Not a netCDF id
NetCDF::recput result = -1
Caught SIGTERM --shutting down
Closing data/pub/decoded/netcdf/surface/04051011_metar.nc with ncid -1
ncclose: ncid -1: Not a netCDF id
Closing data/pub/decoded/netcdf/surface/04051210_metar.nc with ncid 4
Closing data/pub/decoded/netcdf/surface/04051208_metar.nc with ncid 5
Closing data/pub/decoded/netcdf/surface/04051211_metar.nc with ncid 6
Closing data/pub/decoded/netcdf/surface/04051209_metar.nc with ncid 7
[ldm@lead1 surface]$ more metarLog.11505.log
Opening data/pub/decoded/netcdf/surface/04051209_metar.nc with ncid 4
Opening data/pub/decoded/netcdf/surface/04051208_metar.nc with ncid 5
Opening data/pub/decoded/netcdf/surface/04051207_metar.nc with ncid 6
metar metadata file = 
data/pub/decoded/netcdf/surface/../metadata/surface/metar/04051210_metar.meta
Opening data/pub/decoded/netcdf/surface/04051210_metar.nc with ncid 7
ncopen: filename "data/pub/decoded/netcdf/surface/04051010_metar.nc": Not a 
netCDF file
ncdimid: ncid -1: Not a netCDF id
ncdiminq: ncid -1: Not a netCDF id
Opening data/pub/decoded/netcdf/surface/04051010_metar.nc with ncid -1
ncrecinq: ncid -1: Not a netCDF id
NetCDF::recput result = -1


By grepping for the netCDF file name in all log files, it appears that this is occuring on the 
first open of the netCDF file (this assumes that process id is sequential).  Additionally, the 
process does appear to still be "live" after this - I was able to send it a sigterm which 
it caught and responded to.  However, there was another (actually two at the time) metar2nc process 
for the same month running.  The "older" processes are consuming large amounts of CPU.

Is it possible that on this type of error the metar2nc decoder is indicating 
termination to pqact but then not terminating?

Thanks,
Tom.



--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.

------- End of Forwarded Message


==============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
rkambic@xxxxxxxxxxxxxxxx                   WWW: http://www.unidata.ucar.edu/
==============================================================================


  • 2004 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the decoders archives: