[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20030524: LDM or McIDAS Feed Problem
- Subject: 20030524: LDM or McIDAS Feed Problem
- Date: Sat, 24 May 2003 09:30:19 -0600
>From: Jim Koermer <address@hidden>
>Organization: Plymouth State College
>Keywords: 200305212159.h4LLxclL042738 LDM IDD pqing Unisys NOAAPORT
Hi Jim,
>Since your LDM upgrade on cyclone last night, I haven't captured any
>McIDAS data. I see some errors with the png processing
Hmm... I did see images come in and get decoded while I was online, so
I figured that was working correctly.
>and am seeing
>some similar errors with processing data through GEMPAK.
Can you let me know what errors you are seeing in GEMPAK. If it
is related to the Unidata-Wisconsin image decoding by pnga2area,
this is now fixed (see below).
I was going to send you a note about the GEMPAK setup as far as
directories go. What I found on cyclone was pretty messy, and I was
worried that I had interpreted who things were working and setup an
environment where they would continue to work. I guess this is not the
case. I will look into this when I get back on in earnest in a couple
of hours (heading into work). By the way, I found a lot of errors in
~ldm/etc/pqact.conf using 'ldmadmin pqactcheck'. The errors I found
were numerous lines that began with a space. This is illegal in
pqact.conf, so I removed the offending beginning spaces.
>At first, I
>thought that it may have been the relative paths in pqact.conf, so I
>hardwired all of them,
The relative paths will work fine now that /usr/local/ldm points to
/home/ldm instead of /home/ldm/ldm-5.0.6 and you are running
LDM-6.0.11. 'ldmadmin start' always places the user in ~ldm so that
things will be in known locations (e.g., sub directories for relative
paths; core files; etc.).
>but it didn't seem to help. When I stopped and
>restarted the LDM this morning, I noticed that the ldmd.log and png.log
>files are receiving no entries (png no entries since the upgrade).
I noticed that logging was not working when I first logged on. I then
noticed that /etc/syslog.conf was not setup for LDM logging, so I did
the setup. When I went to send a HUP process to syslogd, I thought
that it was not running, so I tried to start it, I tried to see if it
was running using the following as 'root':
ps -eafx | grep syslog
This returned nothing, so I figured syslogd was not working for some
reason. The weird thing, however, is that if I am a user other than
'root', the ps works:
% ps -eafx | grep syslog
81 ?? Ss 1:17.02 /usr/sbin/syslogd -s
It is strange to me that this ps doesn't work for 'root'.
I verified that the entry I added should be OK by adding the same one
to /etc/syslog.conf on pscwx this morning, sending a HUP signal to
syslogd, and then using logger to test it:
logger -p local0.none "test of logger output to syslog"
This sent a message to me and put the same message in the LDM log file
~ldm/logs/ldmd.log which is what I expected. The exact same invocation
of logger on cyclone does not work. I will investigate this further.
>Most other data seem to be processing okay.
I just found and fixed the png decoding error. I had mistakenly put
bin/pnga2area to run as a decoder in pqact.conf, when it should be
decoders/pnga2area. This should work correctly now.
Tom