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

Re: 20040920: Possible pqact issue in LDM?

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: Re: 20040920: Possible pqact issue in LDM?
  • Date: Mon, 20 Sep 2004 12:26:18 -0600
Steven,

>Date: Mon, 20 Sep 2004 12:37:46 -0500
>From: "Steven Danz" <address@hidden>
>Organization: Aviation Weather Center
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20040920: Possible pqact issue in LDM?
>Keywords: 200409091803.i89I3pnJ023109

The above message contained the following:

> True, but that is for the rpc.ldmd log, I'm looking to rotate the
> pqact log.... doesn't look like that is part of the pqact right now.

By default, pqact(1) uses the same logging facility (and logfile) as the
rpc.ldmd processes.

> This is true.

Bizarre.  The fact that the manually-executed pqact(1) catches the
data-products indicates that the in-system pqact(1) must also,  If the
in-system pqact(1) doesn't execute the EXEC entry, then it should log
the reason why in the LDM logfile.

As far as 600 seconds goes, we've seen latencies that are longer, so 
verifying that data-products were actually "missed" (rather than being
delayed) must be done very carefully.  I think the best way would be to
find a "missed" data product that is bracketed by "caught"
data-products that match the same feedtype and pattern entry.

Regards,
Steve Emmerson