20031002: 20031001: 20031001: 20030930: 20030930: upgrade to 6.0.14 and GEMPAK dcmetr problems (cont.)

Kevin,

Sounds like great news.

As an aside, I do run multiple pqact's from ldmd.conf, but each has its own
pqact.conf file, or -p "pattern". So, having multiple pqact lines in ldmd.conf 
itself is not
a limitation, but certainly ones that have the same data sets/actions is.

My ldmd.conf looks like:
# Exec GEMPAK specific pqact processing
exec    "pqact -f NNEXRAD /usr/local/ldm/etc/GEMPAK/pqact.gempak_nexrad"
exec    "pqact -f ANY-NNEXRAD-CRAFT-NIMAGE 
/local/ldm/etc/GEMPAK/pqact.gempak_decoders"
exec    "pqact -f MCIDAS /local/ldm/etc/GEMPAK/pqact.gempak_images"
exec    "pqact -f WMO /local/ldm/etc/GEMPAK/pqact.gempak_nwx"
exec    "pqact -f WMO|SPARE|CONDUIT /local/ldm/etc/GEMPAK/pqact.gempak_upc"
exec    "pqact -f CRAFT -p BZIP2/K[A-E] 
/local/ldm/etc/GEMPAK/pqact.gempak_craft"
exec    "pqact -f CRAFT -p BZIP2/K[F-L] 
/local/ldm/etc/GEMPAK/pqact.gempak_craft"
exec    "pqact -f CRAFT -p BZIP2/K[M-Z] 
/local/ldm/etc/GEMPAK/pqact.gempak_craft"

These are based on the templates found under $NAWIPS/ldm/etc/templates.
The primary reason for these splits is to balance the load on pqact processes 
and
it makes it easier for me to make replacements of the pattern/action files 
without having
to edit sections on a single pqact.conf file (which has other mcidas, idv, etc. 
patterns).

Steve Chiswell



>From: "Kevin W. Thomas" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200310021925.h92JPck1001536

>>Kevin,
>>
>>I see log entries of multiple instances starting up  at your ldm restart time
> .
>>>[1084] 031001/1749 [DC 3]  Starting up. Version 5.6.k
>>>[1086] 031001/1749 [DC 3]  Starting up. Version 5.6.k
>>
>>Its odd to see those 2 process numbers consecutively unless there is a permis
> sion 
>>problem, disk space problem, or more than 1 dcmetr entry.
>>
>>Assuming that you only have 1 dcmetr instance in your pqact.conf file,
>>You may need to make sure that your LDM usr has access to the GEMPAK tree.
>>Do you need to add the user to a RH group?
>>
>>To be safe, you may need to cd to $NAWIPS and do a "chmod -R a+r *"
>>so that the file permissions for the gempak tables are readable by
>>the world in case unpacking the distribution tarfile had different
>>umask settings.
>>
>>Since you say that the file eventually gets created, have you verified that
>>disk space isn't an issue? I'm assuming that the disk is local and not
>>subject to NFS mounting.
>>
>>Steve Chiswell
>
>Steve...
>
>I modified "ldmd.conf" so that I had exactly one data feed.  I modified
>"pqact.conf" so only the "dcmetr" entry was there.  I still got core dumps.
>"Ps" showed two "dcmetr" processes.
>
>I looked at my "dc*.log" files.  All show "dc*" processes are spawned in pairs
> .
>I looked our LDM 5.x systems, and all show only one "dc*" process for all the
>the decoders.  This is obviously the problem.
>
>After looking around, I found the cause.  When I merged the "ldmd.conf" file
>that came with the release with the one that I'd been using, I accidentally
>ended up with two lines that had:
>
>exec "pqact"
>
>Oops!  Getting rid of one of the lines fixed the problem.  I've run for about
>two hours with one "dcmetr" process and no core dumps.  This also explains why
>the raw data files were about twice the size as before.
>
>Future LDM releases may want to check for duplicate "exec" lines in case
>someone accidentally does the same thing that I did.
>
>I'll be coordinating a software upgrade today or tomorrow with my System Admin
>person.
>
>Thanks for your help.
>
>       Kevin W. Thomas
>       Center for Analysis and Prediction of Storms
>       University of Oklahoma
>       Norman, Oklahoma
>       Email:  address@hidden
>