[IDD #VZA-442965]: ldm configuration tweaks

Hi Neal,

re:
> This may be more of a gempak issue than ldm now. I recreated the
> pqact.gempak file using the gen_pqact_GEMDATA.csh script (inserting
> /data/ldm/gempak as the relative gemdata point) and the data is now coming
> into the correct location.

Modifying the GEMPAK pattern-action file(s) is one way of solving the
problem, of course, but that would require that you make the same
modifications each time you install a new version of GEMPAK.  See below
for an outline of the other approach.

re:
> I changed what seems to be a typo on my end in the selinux/config file so
> local10.* became local0.* and that seems to have fixed logging.

Excellent.  Having LDM logging working will be invaluable if you ever
have to troubleshoot data reception issues.

re:
> In the logs I'm seeing a lot of errors regarding decoders (see sample
> below).

> I did notice there was no decoders folder installed in this new
> installation,

The LDM installation does not include creation of the 'util' or 'decoders'
subdirectories under the HOME directory for the user 'ldm'; creation of
these directories is something that the LDM administrator must do for
her/himself.

re:
> so I created the directory and copied everything from $OS_BIN
> to the decoders folder (cp $OS_BIN/dc* /home/ldm/decoders).

Very good.  Did you make sure that the /home/ldm/decoders directory is
in the PATH for your user 'ldm'?  If yes, did you verify that the
GEMPAK decoders will be found?  I ask this since the CShell requires
that the user run a 'rehash' after copying one or more executables
into a directory in one's PATH before they will be found by virtue
of the PATH setting (a 'rehash' is automatically done when the user
logs off and then back on).  So, if you are using the CShell, and
you copied the GEMPAK executables to the /home/ldm/decoders directory
(which is assumed is in 'ldm's PATH) while the LDM was running or
before doing a 'rehash', the decoders would not be found.  The correct
sequence for CShell users would then be:

<as 'ldm'>
cd
mkdir decoders
cp $OS_BIN/dc* decoders
rehash
ldmadmin restart

re:
> That doesn't
> seem to have solved the issue though. I read another support article that
> seemed to relate to this about removing "decoders/" from the pqact files.
> Would that fix the issue if I removed that from pqact.gempak?

You could remove 'decoders/' from the reference to each GEMPAK decoder
in the GEMPAK pattern-action file(s), or you could change the
<datadir-path></datadir-path entry in the LDM registry.xml file.
I recommend changing <datadir-path> to:

<datadir-path>/home/ldm</datadir-path>

NB: after making a change in the registry.xml file, you will need
to stop/restart your LDM for the change to take effect.

If you decide to accept this advice, and if you chose to follow
the advice I sent a previous email (which was a follow-up to
one of Steve's replies to your questions), then you could revert
your GEMPAK pattern-action file(s) actions to write to the data/gempak/...
directories.  The previous advice I gave was to:

<as 'ldm'>
cd ~ldm
ln -s /data/ldm data           <- assuming that ~ldm/data does not
                                  already exist

With this link in place, GEMPAK pattern-action file actions that
specify writing to data/gempak/... directories will work as expected.

re:
> Mar  4 15:56:36 cyclone pqact[2994] ERROR: child 5826 exited with status 1
> (PIPE decoders/dcgrib2 -d /data/ldm/gemp  ak/logs/dcgrib2_GFS.log -e
> GEMTBL=/home/gempak/GEMPAK6.8.0/gempak/tables)
> Mar  4 15:56:36 cyclone pqact[2994] ERROR: [filel.c:295] Deleting failed
> PIPE entry: pid=5826, cmd="decoders/dcgrib  2 -d
> /data/ldm/gempak/logs/dcgrib2_GFS.log -e
> GEMTBL=/home/gempak/GEMPAK6.8.0/gempak/tables"
> Mar  4 15:56:36 cyclone pqact[5827] ERROR: No such file or directory
> Mar  4 15:56:36 cyclone pqact[5827] ERROR: [filel.c:1404] Couldn't execute
> decoder "decoders/dcgrib2"
> Mar  4 15:56:36 cyclone pqact[5827] NOTE: Exiting
 ...

This kind of error will be take care of by modifying the datadir-path
setting in ~ldm/etc/registry.xml to /home/ldm; changing the GEMPAK
pattern-action file(s) actions back to what was created by the
GEMPAK script that created those file(s); making sure that the
/home/ldm/decoders directory is in the PATH for the user 'ldm'
and that they can be found by 'ldm' (verify by running 'which dcgrib2',
while in the /home/ldm directory); and restarting your LDM
('ldmadmin restart').

By the way, the way you phrased the first paragraph of your note
leads me to believe that you created a single pqact.gempak
pattern-action file.  This may work OK for you depending on
what data you want to process with the actions in the file.
It is generally advisable to tell the GEMPAK script that
creates the pattern-action file(s) to not create a single
output file.  This will create several pattern-action files
and will let you know what 'exec' actions to included in
the ~ldm/etc/ldmd.conf file to use all of those pattern-action
files.  The reason for splitting the actions across multiple
pattern-action files is to speed the matching of actions to
data products.  The LDM utility 'pqact' will check each 
pattern-action file action against a product's feedtype
and Product ID to see if the action should be executed.
If all actions are in a single file, then the single instance
of 'pqact' that is assigned to execute the actions will need
to perform the comparison for each action in the pattern-action
file; the comparison does not stop when the first match is
found.

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: VZA-442965
Department: Support IDD
Priority: Normal
Status: Closed