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

[LDM #QAT-399075]: Pqact question

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: [LDM #QAT-399075]: Pqact question
  • Date: Mon, 29 Sep 2014 13:49:12 -0600
Hi Carissa,

> We have seen a product get inserted into the queue and sometimes pqact acts
> on it and sometimes it doesn't.

That shouldn't happen. :-(

> We kind of expected error messages if the
> data was corrupt in some way, but we aren't seeing anything.

pqact(1) doesn't care if the data is corrupt. It does care if the product-queue 
is corrupt and will log that fact if it is.

> If the data is
> corrupt is it possible we would see no evidence of that in the log?

Not from pqact(1). You might see something from the decoder to which pqact(1) 
pipes the product. Does the decoder log problems?

> Or
> could something else be going on? We have 2 different LDM feeds both acting
> the same way on this data.
> 
> Also, you used to be able to search past user questions through your
> website, I can't seem to find that link anymore. Is that function still
> available? I would have looked there first before emailing.

Both of these sequences work:

    www.unidata.ucar.edu -> Support -> Support Archives
    www.unidata.ucar.edu -> Software -> LDM -> Support -> Current Support 
Questions

They wind-up at the same place, which doesn't allow searches of the body of 
emails.

One can always do a Google search using the qualifier "site:unidata.ucar.edu" 
(e.g. "site:unidata.ucar.edu pqact insertion").

We tend to use Google here.

> running ldm-6.11.5 on RHEL
> 
> pqact.conf (last line)
> #  Stick any leftovers in a separate file for later inspection.
> #
> ANY    ^_ELSE_$
> FILE    -close    /dcomdev/us007003/ldmdata/obs/%Y%m%d.leftovers
> 
> [dbndev@t10d1 logs]$ grep SXAK58 ldmd.log.1
> Sep 29 15:19:00 t10d1 pqing[23486] INFO:    29998 20140929151900.995
> FNEXRAD 283  SXAK58 PACR 291518
> Sep 29 15:19:05 t10d1 pqact[23322] INFO:    29998 20140929151900.995
> FNEXRAD 283  SXAK58 PACR 291518
> Sep 29 15:19:05 t10d1 pqact[23322] INFO:                file:
> -close#011/dcomdev/us007003/ldmdata/obs/20140929.leftovers and the ident is
> SXAK58 PACR 291518

The "#011" in the above concerns me. It would appear that the 
product-identifier contained a vertical-tab control character. Could this have 
caused the relevant pqact(1) configuration-file entry to not be triggered?

Would you please send me the relevant pqact(1) configuration-file entry.

> [dbndev@t10d1 logs]$ grep SXAK58 ldmd.log.2
> [dbndev@t10d1 logs]$ grep SXAK58 ldmd.log.3
> [dbndev@t10d1 logs]$ grep SXAK58 ldmd.log.4
> [dbndev@t10d1 logs]$ grep SXAK58 ldmd.log.5
> Sep 28 15:07:55 t10d1 pqing[23486] INFO:    30280 20140928150755.958
> FNEXRAD 186  SXAK58 PACR 281507
> 
> Carissa Klemmer
> NCEP Central Operations
> Production Management Branch Dataflow Team
> 301-683-3835

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: QAT-399075
Department: Support LDM
Priority: Normal
Status: Closed