[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GEMPAK #RUV-555189]: dcmetr not writing to disk or logging
- Subject: [GEMPAK #RUV-555189]: dcmetr not writing to disk or logging
- Date: Fri, 22 Feb 2013 09:59:20 -0700
With no updates data/gempak/logs/dcmetr.log I am worried. I have 6.8.0
decoding through dcmetr on a CentoOS 5 machine (32bit) without problem.
I would add verbose logging to the pattern action (-v 2)
WMO ^S[AP]
PIPE dcmetr -v 2 -a 500 -m 72 -s sfmetar_sa.tbl
-d data/gempak/logs/dcmetr.log
-e GEMTBL=/home/gempak/NAWIPS/gempak/tables
data/gempak/surface/YYYYMMDD_sao.gem
before stopping the ldm, deleting the product queue and creating a new one
(ldmadmin delqueue; ldmadmin mkqueue) and then restart the ldm and check for
updates to dcmetr.log again.
is there anything in ldmd.log around the time you say dcmetr stopped decoding
that could help us? feel free to attach the log back to me and I'll look at it.
Michael
> ldm 6.9.2
> gempak 6.8.0
>
> dcmetr entry:
> WMO ^S[AP]
> PIPE /unidata/ldm/decoders/dcmetr -a 500 -m 72 -s sfmetar_sa.tbl
> -d data/gempak/logs/dcmetr.log
> -e GEMTBL=/unidata/GEMPAK6.8.0/gempak/tables
> data/gempak/surface/YYYYMMDD_sao.gem
>
> No mention in ~ldm/logs/ldmd.log
> No new sao.gem or dcmetr.log updates since 13 Feb when it was working last.
>
> Can't think of what might have thrown a wrench in the works. Most other
> stuff coming and decoded as usual.
>
> What's a diagnostic I might use to figure out what's happening?
>
> -Neil
>
>
>
Ticket Details
===================
Ticket ID: RUV-555189
Department: Support GEMPAK
Priority: Normal
Status: Open