[LDM #OZF-655421]: ldm-6.11.7 and GEMPAK-6.7.0

Hi Patrick,

As promised, I am following-up to a previous email about the GEMPAK
decoder setup on your new machine, monin.snr.missouri.edu...

Here is what I found:

- the setup in the LDM pattern-action file actions for GEMPAK
  reference decoders to be run as 'decoders/dcmetr', etc.

  This assumes that the current working directory for processes
  run by 'pqact' is the HOME directory of the user 'ldm'.  This
  was the case for older versions of the LDM (e.g., LDM-6.8.1),
  but it is not true by default for more recent versions of the
  LDM.  In recent versions of the LDM, the current working
  directory for 'pqact' run actions is defined in the 

  <datadir-path></datadir-path>

  definition in the <pqact></pqact> and <pqsurf></pqsurf> blocks
  in the file ~ldm/etc/registry.xml.  The default current working
  directory for 'pqact' included in recent versions of the LDM is
  ~ldm/var/data.

  Because of this mismatch, _no_ GEMPAK decoders were running
  when I logged on.

  This situation is easily fixed by changing the definition
  of the current working directory by modifying the 
<datadir-path></datadir-path>
  values to be the HOME directory of the LDM.  This is /home/ldm
  in the setup on monin.

- the typical way that users have historically setup the output
  data directory for decode actions was to configure decoder
  actions to write to the data/gempak/... directory hierarchy

  Your setup is not like this; it appears that you and/or Shawn
  configured GEMPAK actions to write to the /data/ldm/data/gempak
  hierarchy.  This is not a problem, but it will require that
  someone hand-modify pattern-action file actions generated by
  the GEMPAK script that creates the pattern-action file actions
  each time a new version of GEMPAK is installed.

  In order to use the pattern-action files generated by GEMPAK
  without modification, one either has to write decoded output
  to the ~ldm/data directory or to make ~ldm/data a link to where
  one wants to write the decoded output.

  I chose to setup two links that will allow you to easily use
  the GEMPAK-generated pattern-action files in the future:

  ~ldm/data -> /data/ldm/data
  ~ldm/logs -> /data/ldm/data/logs

- I noticed that your LDM was not creating log output, so the
  LDM log file, ~ldm/logs/ldmd.log was empty

  The cause for this was that your machine had not been rebooted
  since the SELINUX= value was changed in /etc/selinux/config
  from:

  SELINUX=enforcing

  to:

  SELINUX=permissive

  I assume that Shawn was the one who made the change but had
  not rebooted the machine or run 'setenforce' as 'root' to
  set SELINUX to 'permissive' in the runtime environment.

  With the 'root' access you provided, I ran:

  setenforce 0

  to set the SELINUX enforcement policy without rebooting.

- with the move of the LDM log file from the ~ldm/var/logs directory
  to ~ldm/logs (see above), a change was needed to the /etc/rsyslog.conf
  configuration file for the 'rsyslogd' daemon

  I edited /etc/rsyslog.conf and change the definition for local0.*
  to /home/ldm/logs/ldmd.log.  After making the change, I restarted
  the system logging daemon:

  service rsyslog restart

  I then verified that LDM logging was working by running:

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

  as 'ldm'.

- the last thing I did was to add two actions to the crontab file
  for 'ldm':

  - run 'util/dcrotatelog.csh' (copied from /usr/local/gempak/NAWIPS/bin
    to ~ldm/util) each day

    I have seen quite a few systems that process data using GEMPAK
    decoders that did not rotate the GEMPAK decoder log files
    (saved in ~ldm/data/gempak/logs) on  a regular basis.  The
    net result of this is ever growing GEMPAK log files that
    eventually grow big enough that writing new log messages takes
    a lot of time and consumes system resources (e.g., disk and CPU).

    Your system should be good to go now.

  - setup cron-initiated gathering of system metrics that can help
    diagnose system performance problems if they occur

    The output file used to store performance metrics is
    ~ldm/logs/metrics.txt.  This file is setup to be rotated on
    a regular basis so the output files to not grow too large.

    One can view the performance metrics graphically by running
    'ldmadmin plotmetrics' as 'ldm'.  This requires 'gnuplot' to be
    installed which it is on 'monin' so you are good to go with
    respect to metrics plotting.

One last comment:

- if in the future you decide to ingest and process more data for
  use in GEMPAK, you will want to rerun the GEMPAK script that generates
  pattern-action file actions and tell it to not put all processing
  actions into the same pattern-action file

  Splitting the GEMPAK decoding actions into several 'pqact' pattern-action
  files will insure that all of the data gets processed in as timely
  a manner as possible.

  The GEMPAK script that generates pattern-action files is:

  /usr/local/gempak/NAWIPS/ldm/etc/gen_pqact.csh

Please let me know if you find anything amiss on 'monin'...

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: OZF-655421
Department: Support GEMPAK
Priority: Normal
Status: Closed