[LDM #KKO-947498]: missing feed

Hi Neal,

This is an update on what we have found on your machine...

re: you might need to rebuild GEMPAK from source because of segmentation
violations (core dumps)

> Would that be something I have to do? I was never very involved with the
> actual server setup since my former boss was the one at the training. I'm
> happy to do whatever is needed to get this beast in good working order
> though.

After logging back on to your machine today, I saw that the dcmetr segmentation
violations stopped after I rotated the GEMPAK log files.  I guess that dcmetr
was choking while trying to write a log message to a file that was already
as large as it could be (2 GB).  Given this, there is no need to rebuild
the GEMPAK distribution from source.

Regarding LDM logging:

We setup /etc/syslog.conf to have the correct entries for LDM logging, but
we were still having problems that seemed completely mysterious.  After
some troubleshooting today, we learned the following:

1) in Ubuntu Linux there is a distinct user that runs the syslogd daemon,
   the user 'syslog'.  On most other *nix systems, syslogd is run by 'root'.

   The upshot of 'root' not running syslogd is the user 'syslog' needed
   to be added to the group that the user 'ldm' is in (the group for 'ldm'
   on your machine is ldm).  See 2) for more details.

2) in Ubuntu Linux, the systemwide default file for the Bourne shell (and
   bash, etc.), /etc/profile, sets umask to 022.  If a user does not override
   this setting in his/her own ~/.profile file, then the file mask used
   for file creations (e.g., by the LDM 'newlog' function) is 022 which
   is rw-r-r.

   The upshot of this is that the creation of a new LDM log file when
   'ldmadmin restart' or 'ldmadmin newlog' is run is an ~ldm/logs/ldmd.log
   file that has permissions of rw-r-r.  The user 'ldm' can write to the
   file and so can 'root', but 'syslog' could not.  So, every time the
   LDM log file was rotated, a new log file would be created in which
   syslogd could not write, hence you would have no log messages.

   We fixed the problem by:

   - setting umask to 002 in your ~ldm/.profile file

   Now, when the LDM is restarted or when the log file gets rotated, the
   newly created ldm/logs/ldmd.log file will have permission rw-rw-r.
   Since we added 'syslog' to the 'ldm' group, it can now write to
   the log file.

So... your LDM logging is now working correctly, and GEMPAK decoding
seems to be working.  We are assuming that your machine is once
again creating the "images" that you are expecting.

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