[LDM #LYE-352040]: Do you have some troubleshooting time?

Hi Gerry,

re:
> Thanks. First part of the problem solved: SELinux is, once again, not my
> friend.

I've gotten bitten by SELINUX so many times that I now have a procedure
that I follow when setting up a new LDM installation:

- download, unpack, build, and install the LDM

- create the LDM log file (e.g., 'touch ~/logs/ldmd.log') as the user 'ldm'

  I do this so that 'ldm' owns the file.

- send a HUP message to the syslog daemon:

  % hupsyslog

- test to see if LDM logging is working:

  % ls -alt ~/logs/ldmd.log

  % logger -p local0.debug 'test of LDM logging'

  % ls -alt ~/logs/ldmd.log

  If the LDM log file does not get updated with the 'logger' message,
  I know that something is amiss, so I don't pass Go until I have
  figured out what is not setup correctly (like the need to set
  the SELINUX logging to disabled or permissive).

re:
> I should have remembered that, and I thought I'd cleared that out,
> but I'd missed it.

Been there; done that ;-)

re:
> The explicit 'allow' on the tamu ldm cluster is:
> allow   ANY             ^129\.15\.43\.35$
> allow   ANY             ^129\.15\.43\.68$

The ALLOWs should not have had anything to do with your not seeing
data products being written to disk files since you verified that
you are ALLOWed to REQUEST data in two ways: by running 'ldmadmin watch'
and seeing products arrive, and by running 'notifyme' to the upstream
to verify that it was receiving data AND you are ALLOWed to request
it.

By the way, the second test is not completely definitive.  If the ALLOW for
a machine is limited in some way (e.g., via a regular expression pattern),
the 'notifyme' will show all of the products in the datastream specified
even though the REQUEST will be limited.  I first ran into this "gotcha"
when helping Gilbert get setup to REQUEST NAPLN lightning data from WSI.
WSI's ALLOW limited Gilbert's machine to the USPLN setup of products.
A 'notifyme' run from Gilbert's machine to the WSI machine(s) showed _all_
products that they have in the LIGHTNING datastream (i.e., USPLN, NAPLN,
GLN, etc.), but he could only REQUEST the USPLN portion.  When I dropped
back to consider the situation, I decided that this was a good 'notifyme'
feature and not a nasty bug needing to be quashed.

re:
> I'll forward the pqact.conf along here.

OK, got it.

Observations:

- the first two PCWS actions in the pqact.conf file you sent are identical
  ** except ** for a trailing blank space at the very end of the regular
  expression in the first action

  Is the fact that there are two almost identical entries what was wanted?

  Is the trailing space on the regular expression of the first entry
  included on purpose, or is this a typo?

- I notice that you have two tabs between the feed name and the
  regular expression in the first FSL2 and two PCWS actions:

FSL2<tab><tab>FSL\.CompressedNetCDF\.MADIS\.(.*)\.(....)(..)(..)_(....)\.gz

PCWS<tab><tab>FSL\.CompressedNetCDF\.MADIS\.(acars.*)\.(....)(..)(..)_(....)\.gz<space>

PCWS<tab><tab>FSL\.CompressedNetCDF\.MADIS\.(acars.*)\.(....)(..)(..)_(....)\.gz

  I don't know if using more than one tab will be interpreted incorrectly or not
  (Steve should be able to say whether or not the second tab will be interpreted
  as part of the regular expression or not), but, just in case, I recommend
  removing one of the tabs.

Question if the above change does not solve your problem:

- did you try to use the regular expressions you use for the PCWS entries
  in your pqact.conf file in 'notifyme' invocations to see if they
  match anything?

  Try the following:

<as 'ldm' on the downstream machine>

notifyme -vl- -f PCWS -h idd.tamu.edu -p 
"FSL\.CompressedNetCDF\.MADIS\.(acars.*)\.(....)(..)(..)_(....)\.gz"

  NB: you may need to escape the parentheses in the pattern you specify on the
  'notifyme' command line

  Does this show any matches?

NB:

- remember that after making any change to a 'pqact' pattern-action file,
  you should _always_ run the gross syntax checker before sending a HUP
  telling the LDM to reread all pattern-action files:

-- edit pqact.conf
ldmadmin pqactcheck  - if an error is shown, go back and re-edit pqact.conf
ldmadmin pqactHUP

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: LYE-352040
Department: Support LDM
Priority: Normal
Status: Closed