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

20000128: testing mcidas 7.604 (cont.)

>From: David Fitzgerald <address@hidden>
>Organization: Millersville University of Pennsylvania
>Keywords: 200001262144.OAA16099 McIDAS-X 7.6

Dave,

>Ok I checked the things you mentioned below and they look ok.  The
>environment variables are set up as per the testing section: `which mcidas`
>looks at $HOME/mcidas7.6/src/mcidas.  The .mctmp directory IS writable by
>mcidas, permissions are drwx--l--- , owned by mcidas and in the ldm group,
>which is the same group as it always has been.

This looks a little odd.  On our systems, the permissions on .mctmp
are:

drwxrwxr-x   3 mcidas   ustaff       512 Jan 31 11:50 .mctmp/

>IF you wish to log on to twister.millersv.edu as mcidas and poke around,
>feel free to do so.  Use secure shell if you have it, we've caught some
>students sniffing for passwords already this semester.

OK, I did.  I ran into the same problems you did and more.

To begin with, I cleaned up a preexisting McIDAS-X session:

<login as mcidas>
cd .mctmp
rm -rf 100
ipcrm -m 100

Since I was suspicious about the permissions on ~mcidas/.mctmp, I did
the following from snowball:

<login as mcidas>
rmdir .mctmp
mkdir .mctmp

Now the directory permissions on .mctmp are what I would expect.  The
next thing I tried to do from the command line was:

setenv MCDATA /software/mcidas/mcidas7.6/data
setenv MCPATH ${MCDATA}:/software/mcidas/mcidas7.6/src
setenv MCGUI  /software/mcidas/mcidas7.6/src
setenv PATH  ${MCGUI}:$PATH
cd mcidas7.6/data
dmap.k AREA

This hung in the way that you originally reported, so the change to .mctmp
was of no help.

I then did:

cd ../src
ldd dmap.k

and got:

/software/mcidas/mcidas7.6/src% ldd dmap.k
        libgen.so.1 =>   (file not found)
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
        libF77.so.4 =>   /software/SUNWspro/lib/libF77.so.4
        libM77.so.2 =>   /software/SUNWspro/lib/libM77.so.2
        libsunmath.so.1 =>       /software/SUNWspro/lib/libsunmath.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2

So, on snowball libgen.so can't be found.

Over on twister, an ls showed:

cd mcidas7.6/src
ls -l dmap.k
dmap.k: Stale NFS file handle

An ldd shows the same thing:

ldd dmap.k
ldd: dmap.k: cannot open file: Stale NFS file handle

So, it looks like there might be a automounter problem of some kind.

In trying to figure out why McIDAS routines were waiting, I noticed
that they were not creating a lock file in /tmp.  On twister, the
/tmp/mclock directory was not even being created.  To test if creating
one would help, I made one by hand.  This had no effect unfortunately.

>Its probably something very easy and silly that I missed but am not seeing.

If it is something silly, then I can't see it either!  I bet, however, that
it has something to do with either shared memory, or automounted file
systems.  What I would do to test this is reboot both snowball and twister
in sequence to see if this is beneficial in any way.  Since I realize that
this would be cause a big inconvenience during the day, I don't expect
that you could get around to doing this for awhile

>Thanks for your help!

If I could have pinpointed the problem, I would feel a whole lot better.
I will have to revisit your machine later this evening when the net
is quieter.  I ran into what you were telling us: connectivity is
pretty bad.

Tom