20030728: McIDAS dmsyn.k runaway process

>From: Thomas Mote <address@hidden>
>Organization: UGa
>Keywords: 200307281953.h6SJrKLd007297

Hi Tom,

>I think I have successfully built McIDAS 2002b on cacimbo with
>the decoders. Our tech people installed all the include files I needed
>a couple of weeks ago and I built it shortly thereafter. I've been
>tied up since then.

OK.

>I noticed today that I had a dmsyn.k process that had chewed up
>hours of cpu time and was using all of the current cpu time.
>I restared the ldm and we're fine for now.
>Is there anything obvious I could have missed? When we last
>e-mailed, you thought the upgrade from 7.8 to 2002b would
>take care of this issue.

Yes, the v2002b addendum had code mods that should prevent the dmsyn.k
problem.  The installation of this addendum fixed the problem on
other systems that were experiencing the same problem (excessive
CPU use): RedHat 8.0 Linux and Compaq Tru64 Unix 5.1.

>This only occurred after we upgraded the
>OS from RH7 to RH8 earlier this summer. I never noticed
>any similar problems prior to that point.

The same problem was not seen on RedHat 6.x or 7.x Linux.

>I almost hate to deal with this as I just found out today we're going
>to order a replacement for this system.

I am very suprised that the upgrade to v2002b did not cure the problem.
Could I logon to the machine and take a look?  My inclination would
be to:

- verify that the v2002b modified files were indeed unpacked into
  the ~mcidas/mcidas2002/src directory

- that 'make all' actually remade the necessary binaries

- that the binaries that got remade got correctly installed in the
  ~mcidas/bin directory

I might even do the following:

<login as 'mcidas'>

cd ~mcidas/mcidas2002/src
make clobber
make all VENDOR=-g77
make install.bin install.xcdbin VENDOR=-g77

I would do the last installation step while the LDM was stopped.

>(It's on a three-year
>replacement cycle through university tech fee money.)

Nice!

>The replacement
>should be a nice system. We're getting a GigE connection
>straight into the university's core fiber loop, so that should give
>us a faster network connection. It will still have a direct fiber connection
>to the NOAAport system. Of course, the replacement will be faster
>with more disk space, etc. With the NOAAport system feeding it, we'll
>probably have a system all Unidata institutions will envy ;-) (just 
>kidding).

Sounds great, and I think that other institutions _will_ be envious!

>Any advice is appreciated. I can let you on for a peek if it would help.

I am more than happy to jump onto cacimbo and snoop around.  If you
want to give me access, please send the password for the 'mcidas' and
'ldm' accounts to my private email address, address@hidden,
_without_ specifying the machine or account names.

Tom