20000203: Millersville mount problems (cont.)

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

Mike (with CC to Dave),

>I've looked at around quite a bit in an attempt to figure out the problem.

I appreciate that.

>I would like to run the same test you did, but don't know what the command
>sequence to produce the failure looked like?

I just looged onto twister and tried to run:

mcenv

to see if a McIDAS environment could be created.  The process seemed to
hang in the same place as before.

To verify this, I ran:

truss mcenv

and got the same wait condition:

sigprocmask(SIG_SETMASK, 0xFFBEF61C, 0x00000000) = 0
unlink("/tmp/mclock/34501")                     Err#2 ENOENT
mkdir("/software/mcidas/.mctmp/34501", 0700)    = 0
open("/software/mcidas/.mctmp/34501/BASICVV1", O_RDWR|O_CREAT, 0600) = 4
write(4, "80", 1)                               = 1
close(4)                                        = 0
open("/software/mcidas/.mctmp/34501/FRAMED", O_RDWR|O_CREAT, 0600) = 4
write(4, "80", 1)                               = 1
close(4)                                        = 0
open("/software/mcidas/.mctmp/34501/FRAMENH.001", O_RDWR|O_CREAT, 0600) = 4
write(4, "80", 1)                               = 1
close(4)                                        = 0
open("/software/mcidas/.mctmp/34501/TERMCHAR.001", O_RDWR|O_CREAT, 0600) = 4
write(4, "80", 1)                               = 1
close(4)                                        = 0
open("/software/mcidas/.mctmp/34501/GRAPHICS.KEY", O_RDWR|O_CREAT, 0600) = 4
write(4, "80", 1)                               = 1
close(4)                                        = 0
open("/software/mcidas/.mctmp/34501/STRTABLE", O_RDWR|O_CREAT, 0600) = 4
write(4, "80", 1)                               = 1
close(4)                                        = 0
open("/software/mcidas/.mctmp/34501/mcclean.lock", O_RDWR|O_CREAT, 0600) = 4
write(4, "80", 1)                               = 1
fcntl(4, F_GETFD, 0x00000000)                   = 0
fcntl(4, F_SETFD, 0x00000001)                   = 0

I let this sit there for quite awhile; a run of mcenv as the user running
the LDM worked as it should.  The home directory for that user is not,
however, on an NFS mounted file system.

>First, I've killed the group
>setuid bit which may force the mandatory locking -- now I need the run the
>test again.

OK, did you need to do anything different than what I have above?

>Also, although I can't find and specific mention of this
>problem, I note that twister doesn't have any of the kernel/nfs patches
>installed which might be helpful in eliminating some of the possibilities.

OK, since Dave is CCed on this message, he will see your comment.

Since the 'mcidas' account is/should not really be used for anything other
than supervisory activities, this problem may be finessed by:

o killing all errant McIDAS-X processes in the 'mcidas' account
o removing the ~mcidas/.mctmp directory
o creating a .mctmp directory for 'mcidas' in /tmp
o making a link to /tmp/mctmp directory from ~mcidas/.mctmp

I just tried this and it works like it should.  A shared memory segment
is created; the subdirectory of .mctmp is created; the fcntl on mcclean.lock
finishes correctly, and control is returned to the user:

<kill the 'truss mcenv' invocation>
rm -rf .mctmp                       <- this would not work until you removed the
                                       group setuid bit
mkdir /tmp/mctmp
ln -s /tmp/mctmp .mctmp

mcenv

ls -al /tmp/mctmp
total 48
drwxrwxr-x   3 mcidas   100          107 Feb  8 10:23 .
drwxrwxrwt   6 sys      sys          365 Feb  8 10:26 ..
drwx------   2 mcidas   100          410 Feb  8 10:23 34601

cd workdata
dmap.k AREA9
PERM      SIZE LAST CHANGED FILENAME DIRECTORY
---- --------- ------------ -------- ---------
-rw-   1503728 May 26  1998 AREA9010 /software/mcidas/data
-rw-   1503728 May 26  1998 AREA9011 /software/mcidas/data
-rw-   1543904 May 26  1998 AREA9012 /software/mcidas/data
-rw-   1003728 May 26  1998 AREA9013 /software/mcidas/data
-rw-   1003728 May 26  1998 AREA9014 /software/mcidas/data
-rw-    897680 May 26  1998 AREA9015 /software/mcidas/data
-rw-    608288 May 26  1998 AREA9016 /software/mcidas/data
-rw-    565512 May 26  1998 AREA9017 /software/mcidas/data
-rw-    311008 May 26  1998 AREA9018 /software/mcidas/data
-rw-    714288 May 26  1998 AREA9019 /software/mcidas/data
-rw-       768 Nov 25  1996 AREA9982 /software/mcidas/data
-rw-       768 Nov 25  1996 AREA9983 /software/mcidas/data
-rw-      2816 Jun 02  1998 AREA9995 /software/mcidas/data
9659944 bytes in 13 files

As you can see, with the .mctmp directory in /tmp, McIDAS now works.

I believe that the "real" solution most likely lies in needed OS patches
as you hinted at.  Since Dave indicated that he did not want to muck with
snowball since he is getting a new machine that will act as a server, this
hack may well tide him through until the upgrade.

Tom
--
+-----------------------------------------------------------------------------+
* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*
+-----------------------------------------------------------------------------+