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

[McIDAS #IWJ-443798]: MCIDAS Software Upgrade at NGC

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: [McIDAS #IWJ-443798]: MCIDAS Software Upgrade at NGC
  • Date: Tue, 17 Jan 2012 11:31:23 -0700
Hi again Martha,

This email must have been received while I was responding to the previous one 
:-)

re:
> I got some more info via ldmd.log - sorry this is disjointed, I have
> people working here in my house and I am trying to juggle ldm and keep my
> dog from bothering them.

:-)

re:
> Anyhow I am attaching ldmd.log with more information

There is nothing in the ldmd.log file you included with this exchange that shows
an attempt to FILE a product.

Question:

- are you sure you sent the USR2 signal to the correct 'pqact' invocation?

  Again, the way to find out the process ID of the appropriate 'pqact'
  invocation is:

  <as 'ldm'>

  ps -fu ldm

  -- Get the process ID for the 'pqact' invocation that is using the 
pqact.conf_nnexrad_file
     pattern-action file.

  -- send that process a USR2 signal

NB: putting LDM routines into debug logging will cause a LOT of output to be 
written
to the ~ldm/logs/ldmd.log file.  Make sure that you stop the verbose/debug 
logging
after you have figured things out.  This can be done by sending two more USR2 
signals
to the appropriate 'pqact' invocation, or, more simply, by restarting your LDM 
using
'ldmadmin restart'.

By the way, one thing caught my eye in the log output you sent.  Lines like:

Jan 17 18:06:31 noaapxcd pqact[29729] DEBUG: pq_sequence(): 
time(insert)-time(create): 2628.9805 s

are suspicious since the delta is so large (2628.9805 seconds.  Given that you 
are REQUESTing
data from a machine that is _presumably_ in your same subnet, such a high 
latency should
be impossible.  Perhaps the clock on the receiving machine is off?  If no, 
perhaps the
clock on the sending machine is off?

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: IWJ-443798
Department: Support McIDAS
Priority: Normal
Status: Closed