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

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



Hi Martha,

re:
> I had to leave early, and on the way home thought of one explanation -
> in the nnexrad pqact file i used "data/nexrad" rather than "/data/nexrad"
> and I remembered back when you were helping us with CONDUIT that the initial
> / was important.

Yes, use of data/nexrad implies ~ldm/data/nexrad (assuming that LDMHOME was
defined to be ~ldm when 'configure' was run during the build of the version
of the LDM you are suing).  /data/nexrad refers to a specific location which
may or may not be ~ldm/data (there would have to be a soft link to make them
the same).

re:
> When I got on via our VPN
> and checked, I saw nexrad data in /usr/local/ldm/data/nexrad, which is
> not where we want it.

OK.

re:
> So I edited the pqact file so that the directory spec was "/data/nexrad"
> and restarted ldm.

Quick comment:

- one does not need to stop/restart the LDM after making a change to an
  action in a pattern-action file

  All you had to do was:

  <as 'ldm' on noaaportxcd>
  ldmadmin pqactcheck

  -- assuming that there were no errors reported run:

  ldmadmin pqactHUP

  This sends a HUP signal to all 'pqact' invocations which tells them
  to reread their pattern-action files.

re:
> And no data so far has showed up.

Is the directory /data/nexrad writable by the user running your LDM?
If not, this would explain the lack of data being FILEed.

re:
> The results of the notifyme showed nexrad coming in.

This jives with your comment that data was being filed into subdirectories
of ~ldm/data/nexrad, and the observation also shows that there is nothing
systematically wrong with the action.

re:
> So I put ldm for nexrad into debug, and saw this in the log
> 
> Jan 17 17:44:13 noaapxcd pqcheck[29694] NOTE: Exiting
> Jan 17 17:44:13 noaapxcd ldmd[29725] NOTE: Starting Up (version: 6.9.8; 
> built: Aug  2 2011 11:02:02)
> Jan 17 17:44:13 noaapxcd ldmd[29725] NOTE: Using local address 0.0.0.0:388
> Jan 17 17:44:13 noaapxcd noaapnew.it-protect.com[29731] NOTE: Starting
> Up(6.9.8): noaapnew.it-protect.com:388 20120117164413.655 TS_ENDT {{ANY,  
> ".*"}}
> Jan 17 17:44:13 noaapxcd noaapnew.it-protect.com[29731] NOTE: LDM-6 desired 
> product-class: 20120117164413.655 TS_ENDT {{ANY,  ".*"},{NONE, 
> "SIG=efe7c5157f50a8c8cf0b10a9d6e3c83e"}}
> Jan 17 17:44:13 noaapxcd pqact[29728] NOTE: Starting Up
> Jan 17 17:44:13 noaapxcd pqact[29728] NOTE: Starting from insertion-time 
> 2012-01-17 17:43:35.299923 UTC
> Jan 17 17:44:13 noaapxcd pqact[29730] NOTE: Starting Up
> Jan 17 17:44:13 noaapxcd pqact[29729] NOTE: Starting Up
> Jan 17 17:44:13 noaapxcd pqact[29730] NOTE: Starting from insertion-time 
> 2012-01-17 17:43:35.299923 UTC
> Jan 17 17:44:13 noaapxcd pqact[29729] NOTE: Starting from insertion-time 
> 2012-01-17 17:43:35.299923 UTC
> Jan 17 17:44:13 noaapxcd noaapnew.it-protect.com[29731] NOTE: Upstream LDM-6 
> on noaapnew.it-protect.com is willing to be a primary feeder
> Jan 17 17:44:32 noaapxcd pqact[29730] WARN: Processed oldest product in 
> queue: 0.000207 s
> Jan 17 17:44:32 noaapxcd pqact[29729] WARN: Processed oldest product in 
> queue: 0.000221 s
> Jan 17 17:44:32 noaapxcd pqact[29728] WARN: Processed oldest product in 
> queue: 0.000219 s
> Jan 17 17:44:56 noaapxcd 127.0.0.1(noti)[29812] NOTE: Starting Up(6.9.8/5): 
> 20120117164456.210 TS_ENDT {{NEXRAD3,  ".*"}}
> Jan 17 17:44:56 noaapxcd 127.0.0.1(noti)[29812] NOTE: topo:  127.0.0.1 NEXRAD3
> Jan 17 17:45:00 noaapxcd 127.0.0.1(noti)[29812] ERROR: SDUS75 KVEF 171645 
> /pNETESX: RPC: Unable to receive
> Jan 17 17:45:00 noaapxcd 127.0.0.1(noti)[29812] ERROR: pq_sequence failed: 
> Input/output error (errno = 5)
> Jan 17 17:45:00 noaapxcd ldmd[29725] NOTE: child 29812 exited with status 1
> 
> Does this mean that ldm will refuse to write nexrad data after this error?

No. The last line in the listing you provided shows that the process with 
process ID
29812 exited with status 1.  The lines right above show that this process was a
'notifyme' (noti) invocation.  The "error" is simply a reflection of you 
terminating
the 'notifyme' invocation.  There is nothing in this log file snippit that seems
to relate to the 'pqact' processing of NEXRAD3 data.

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


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.