>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/*
+-----------------------------------------------------------------------------+
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.