NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
>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