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

[LDM #FLA-146766]: ldm file writes



Steve,

> There was nothing in the ldmd.log file that would indicate a write problem.
> In my initial email, I included the log entries related to one of the metar
> products processing. Does it indicate a problem when there is a
> "fl_removeAndFree()"
> entry only for the networked write and none for the local disk write?

The filings of the metar to local disk and network disk should be identical
because both actions are "STDIOFILE -close ..."; Consequently, there
*should* have been a similar "fl_removeAndFree()" message logged for the
filing to local disk. The fact that there wasn't would seem to indicate that
the processing that was actually occurring wasn't "STDIOFILE -close" for the
local disk.

> By the way, we haven't had a problem since I restarted the ldm last night.
> I had changed from -flush to -close, but the problem persisted after a
> ldmadmin pqactHUP.

Odd. That command should have caused all pqact(1) processes to close all 
open file descriptors and re-read their configuration files.

How many pqact(1) processes do you have. Does each one have its own
configuration-file?

> I then did a stop/clean/start series, and things have
> been good since. Time will tell if that was the fix. If it isn't, I'll try
> FILE instead of STDIOFILE. If it was the -flush, do you have any thoughts
> why that would suddenly become a problem?

None.

> We've been running various LDM
> versions since the dinosaur era and have never  had a problem with the
> -flush option. Might a small queue and increasing NOAAPort content be a
> problem for -flush?

I don't see how. A small queue might cause the pqact(1) process to miss a
product (in which case it would log a warning) but it shouldn't affect a
product being processed.

Please keep me apprised.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: FLA-146766
Department: Support LDM
Priority: Normal
Status: Closed
===================
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.