[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030703: McIDAS decoding problem

>From: "Thomas L. Mote" <address@hidden>
>Organization: UGA
>Keywords: 200307031521.h63FLfLd024002 McIDAS-X -XCD v2002b LDM-6

Hi Tom,

>I've noticed a couple of McIDAS issues that I was hoping you could
>help with. These started after we upgraded cacimbo to RH8 about 2 months
>ago. (It had been running a patched version of the same OS for three
>years, but the university would no longer support RH7.0.) I'm just
>now getting around to dealing with this.
>First, I'm occasionally noticing that a process like dmraob.k
>or dmsfc.k will be using all the CPU time. I'll stop and restart
>the ldm, and it will be fine. Just a few minutes ago, I noticed
>dmraob.k was using 99.6% of the CPU for an extended period.
>A restart of the ldm and it was fine.

This sounds exactly like a problem I fixed in the v2002b addendum.  If
you are still running a version prior to this (check this by listing
out the contents of ~mcidas/data/VERSION.TXT), then you need to install
the addendum.  I first saw this problme on Gilbert Sebenste's NIU
machine.  I traced the problem down to a severe memory leak in the
station table database access routines.  Installation of the v2002b
addendum has fixed problems like this not only on more recent versions
of Linux (8.0+) but also on Compaq/DEC OSF/1.

>Secondly, it doesn't seem like our ADDE server is making the
>NEXRAD products available, although everything else seems to be
>there. I don't recall changing anything there, so I'm not sure
>what the problem would be.

This most likely an ADDE configuration problem.  It could be that a
file got damaged in the upgrade, or, more probably, that the setup in
the system files got changed.  The first thing I would do in
troubleshooting this is to reinstall the McIDAS ADDE remote server
stuff.  This is a very simple process, but it must be done as 'root'.
Here are the steps that you should have 'root' do _after_ you install
the v2002b addendum:

<login as 'root'>
cd /home/mcidas

sh ./mcinet2002.sh uninstall mcadde
sh ./mcinet2002.sh install mcadde

Just after I wrote this I did a simple telnet test to cacimbo on port

% telnet cacimbo.ggy.uga.edu 500
Connected to cacimbo.ggy.uga.edu.
Escape character is '^]'.
^CConnection closed.

The fact that cacimbo is listening on port 500 indicates that the ADDE
server installation is there and probably working.  One problem you may
have run into during the upgrade from RH 7.0 to 8.0 is an incorrect
conversion of the 7.0 /etc/inetd.conf entries into 8.0 /etc/xinetd.d
files.  The uninstall/install steps listed above should fix this.

The other thing that is possible is that there are conflicting entries
in /etc/services for port 500 and/or 503.  After doing the
uninstall/install steps above, please check to make sure that the only
entries in /etc/services for 500 and 503 are the ones for McIDAS.

If all of the above fails and you continue to have problems, I am
always willing to logon and take a hard look at your setup.

By the way, I want to take this opportunity to encourage you to upgrade
your LDM to the latest release of LDM-6 and to start reporting real
time statistcs back to us.  We are offering everyone an installation
and tuning service: we will do the installation and tuning of your
ldmd.conf entries to maximize efficiency as long as we are given the
appropriate logins for 'ldm' and possibly 'root'.  'root' access is
need for the last bit of the LDM installation; it is not absolutely
necessary that we have this access if you are willing to perform the
last configuration step.

Please let me know if you are interested in our LDM installation/tuning

>Thanks for your help.

No worries.  Talk to you later...


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.