20011206: 20011128: McIDAS vis-a-via Solaris 7/8 (cont.)

>From: "James R. Frysinger" <address@hidden>
>Organization: College of Charleston
>Keywords: 200111061842.fA6Igt112242 LDM binary install

Jim,

>Made it safely to DC and back without developing a case of
>committee-paralysis. Seems like the Special Theory of Relativity ought
>to include a section on the distortion of time due to the gravitational
>fields generated by committees.

:-)

>BTW, you might be interested to know that my IEEE proposed standard on
>"Prefixes for Binary Multiples" got approved in committee and I will be
>working towards getting it balloted by IEEE staff. This parallels the
>IEC standard and will make them an American National Standard (ANSI).
>If it passes, that mebi neat! Ah, well, I digress...

Congratulations!

>We're running into some peculiarities here. The stuff below is probably 
>not in a very logical order, but then neither am I.
>
>Last night, Jim Neff and I installed the start script in .../rc2.d
>(we're on Solaris, recall) and tried a reboot. Wow, was that exciting!
>We had found earlier that a number of ldm processes were running (using
>ps -ef) and that there were two instances of ldmd running somehow (near
>as I can figure).

Perhaps you are referring to rpc.ldmd?  There will be one of these
processes running for each request line in ~ldm/etc/ldmd.conf, and one
for each downstream feed you are providing.  Since you are currently
not relaying data, yours will only be from the request lines in
ldmd.conf.

>I did ldmadmin stop (as ldm) and that stopped one
>server but I had to su to root to do ldmadmin stop to get the other one
>server to stop.

This is not good.  It is possible that the other rpc.ldmd would have
eventually exited if you had waited long enough.  An 'ldmadmin stop'
does not kill processes, it sends them a signal to exit when they
are finished with the current product.

One quick comment.  The LDM should _never_ (ever!) be run as 'root'!

>Thinking that was a fluke we went ahead with the above
>installation of the startup script in .../rc2.d. When we rebooted it
>looked like several processes were trying to start up but were
>failing.

What were the symptoms?  What did the ~ldm/logs/ldmd.log file have in
it?

>By putting echo tags in front of and behind
>
>   /bin/su - ldm -c "$LDMBIN/ldmadmin start"
>
>in the startup script, we deduced that this was the step causing the
>problems.

>Other symptoms were that the system was trying to come up in
>Open Windows instead of our usual CDE and also that /dev/fb was being
>addressed, mounted, or something (in between our two echo tags). I have
>no idea what /dev/fb is.

I will have to discuss this with our LDM experts.  I think that the
problem may be that you are trying to start the ldm from the wrong place.

>And I'll have to punch the pubs some more to see what
>
>   # $Id$
>
>just below the shell script bang does in a sh script. The closest thing
>I can find on this is something about a login shell script having a
>UID, GID, EUID, and EGID when invoked. Is this line causing ldm to "log
>on" as a user when the boot process runs this script? That's what
>appeared to be happening last night.

>Here is a cut and paste of my startup script:
>#! /bin/sh
># $Id$
>#
>PATH=/bin:/usr/bin:/usr/etc:/usr/ucb; export PATH
>LDMHOME=/export/home/ldm
>LDMBIN=$LDMHOME/bin
>DECODEBIN=$LDMHOME/decoders
>UTILBIN=$LDMHOME/util
> 
>case "$1" in
> 
>'start')
>        if [ -x $LDMBIN/ldmadmin ] ; then
>                PATH=$PATH:$LDMBIN:$DECODEBIN:$UTILBIN:/usr/local/bin; 
>export PATH
>                echo "starting $LDMBIN/rpc.ldmd using ldmadmin start."
>                /bin/su - ldm -c "$LDMBIN/ldmadmin delqueue"
>                /bin/su - ldm -c "$LDMBIN/ldmadmin mkqueue"
>                /bin/su - ldm -c "$LDMBIN/ldmadmin delsurfqueue"
>                /bin/su - ldm -c "$LDMBIN/ldmadmin mksurfqueue"
>                /bin/su - ldm -c "$LDMBIN/ldmadmin start"
>        fi
>        ;;
>'stop')
>        if [ -x $LDMBIN/ldmadmin ] ; then
>                $LDMBIN/ldmadmin stop
>        fi
>        ;;
>esac

Looks OK at this point.  I will get back to you on the proper place to
start the LDM at boot.

>Later (last night), I found that had made a typo and had linked runtime
>to ldm.5.1.2 instead of ldm-5.1.4. That was fixed but apparently this
>did not solve the problem.

After upgrading from 5.1.2 to 5.1.4, you will have to delete and remake
your LDM queue:

<login as 'ldm'>
ldmadmin stop
ldmadmin delqueue
ldmadmin mkqueue

>Just now, after attempting ldmadmin start
>(which hangs), I noticed a version problem on pqsurf.pq (version 6
>present, version 7 expected). So I did ldmadmin delsurfqueue and then
>ldmadmin mksurfqueue. This (now that the erroneous runtime link has
>been fixed) has allowed ldmadmin to start properly (I think). Do you
>suppose that this might have been the problem with our startup script
>in rc2.d?

Yes.  Also delete and remake the LDM queue.

>I remember now that either you told me or I read that there
>had been a change in the formatting of surfqueue.

Yup.

>Since I'm working from home at the moment, I have not re-enabled the
>startup script in rc2.d, but will when I can work at the console --
>perhaps tomorrow.

OK.

>Another question I have come up with is on netcheck.conf. Should I be
>tailoring this, for example, inserting the proper links and mail
>addresses?

Since I am not the LDM expert, I will have to check and get back to you.

>I think I have the crontabs and ldmd.conf files edited properly, but
>you may wish to check them. I have not yet set up the pqact.conf file.

OK.

>That looks like it will be easier to do on campus, especially since
>that's where my LDM SysAdmin Handbook (from last year) is located.

I agree.

>In the meantime, I have done ldmadmin stop. Looks like I'm down to 
>figuring out my startup script problems for rc2.d and setting up my 
>decoders.

Yup.

>>From address@hidden Thu Dec  6 21:25:56 2001
>
>I think I've lost my way. I'm surrounded by decoder information. As I 
>understand it from your Nov 25 14:48.28 I should go to
>
>http://www.unidata.ucar.edu/packages/mcidas/mcidd/ldm-mcidas.html
>
>and do the LDM-MCIDAS installation per those instructions.

Yes.

>(I still
>haven't figured out the click-sequence that gets me from the mcidas
>home page to that address!)

ldm-mcidas can be reached from the menu located in the top frame:

'DOCS' 'INSTALL' 'HOT TOPICS' 'IMAGERY' 'LDM-MCIDAS' 'PLATFORMS' 'SUPPORT'

>And that gives me the decoders I need.
>Right?

The decoders for:

o imagery in the Unidata-Wisconsin datastream
o NLDN lightning decoder
o FSL wind profiler decoder

All the other decoders are part of the McIDAS-XCD package.

>At least the IDD data types seem to be represented. I guess that
>leaves a few, such as NLDN, NEXRAD, and so forth.

Yes.  NEXRAD files are FILEd directly by the LDM, not decoded.

>Then on the McIDAS installation pages I see a bunch of other stuff
>about decoders.

McIDAS-XCD decoders are for all of the NOAAPORT products that need to
be converted to a package-specific format.

>Watta melee! One of the things that makes this hard for
>me is the parallel layout of the material.

Point taken. The problem is that we are dealing with two different packages
here.  I will update my McIDAS web pages to include the ldm-mcidas stuff
and specific actions for NEXRAD filing so that there is more of a "one
stop shopping".

>I don't see any overall
>roadmap for building an installation from scratch.

We talked about this earlier.  An overview is called for and will be done
when I can get the time.  In the meantime, if one works linearly through
the McIDAS installation pages, the only thing left to be done is ldm-mcidas.

>Your help in keeping
>me on the path is all that is getting me through at the moment.

I understand.  The process would seem more clear if it had been done
from start to end with no distractions (a luxury?).  I will use your
experiences (with others) to put together an installation roadmap
and checklist.  This should make the process more cookbook.

Tom