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

20000128: McIDAS problems (cont.)

>From: Michael Voss <address@hidden>
>Organization: SJSU
>Keywords: 200001181849.LAA08980 McIDAS-X NLDNPLT

Mike,

re: multiple copies of McIDAS being run from the same account
>Synoptic lab class is going...is it OK to have two sessions going by the same 
>user?

Yes, but usually not from different machines.  The problem here is in
how McIDAS tries to clean up after incompletely exited sessions.  The standard
action for the startup is to run a program called mccheck that looks
to see if there is a lock in the /tmp/mclock directory that indicates
that a McIDAS session is active.  Since /tmp is always local to a machine,
one machine's /tmp will not contain lock information about a session
run in an account from a different machine.  When the lock file is
not found, mccheck decides that the hidden directories under ~user/.mctmp
are remnants from inproperly exited sessions, and it will remove
the files in them.  This is disasterous for the user's session that
is still running from a different machine.

There are different ways around this problem:

o only allow one session from an account at a time
o remove the mccheck cleanup step from the McIDAS startup
o create a setup where a login to an account from a different machine
  puts the user in a unique McIDAS environment

The first option is the easiest to do, but limits a site setting up
an account for classes (e.g. met171, etc.).

The second option requires that you comment out the '-c mccheck' line
from each user's .mcidasrc file.

The third option is a lot more complicated, but has some attractions.

Let's concentrate on the second option.  Here is what I would do:

o to remove the automatic cleanup of crashed sessions during McIDAS
  startup, you should

  <login as 'mcidas'>
  cd bin
  <edit mcidasx>

  Read the section that pertains to mccheck and then.

  change:

-c '!@exec mccheck'

  to:


#-c '!@exec mccheck'

o <as 'root'>
  remove each McIDAS users .mcidasrc file

o the next time a user starts a McIDAS-X session using the standard
  'mcidas' invocation, ~user/.mcidasrc will be recreated but the
  running of mccheck will be commented out.  This will not work (yet),
  hoever, if you use the GUI startup method, 'mcidas config'.

One word about the problems you can run into when running more than one
session from a single account.  Concurrent sessions will share the same
McIDAS working directory (~mcidas/workdata for 'mcidas' and ~user/mcidas/data
for 'user').  Files in this directory will, therefore, be shared by
those concurrent sessions.  What one user does can affect what a different
user is doing.  One example of this is the use by the Fkey menu and MCGUI
systems of STRTABLE values and use of the VIRTual graphic file, VIRT9300.

Here is a quick example that could illustrate the consequences.  Suppose
one user decides to plot a sounding from Denver, CO.  S/he selects
station ID number 72469 from the GUI selector that is popped up from
the Fkey menu.   S/he plots the diagram and then goes on to other
things.  The second user decides to do the same thing, but for a different
station like Grand Junction, CO.  The IDN for KGJT is 72476.  S/he
plots this diagram.  The first user decides to replot the same skewt
and goes back to the selector.  Instead of seeing Denver as the default,
S/he will see Grand Junction.  This will be unexpected and perhaps
disconcerting.

There are many more examples of how the different concurrent sessions could
interfere with each other, but I am sure you get the idea.

re: some cleanup needed in the ~met171/mcidas/data directory
>OK

This comment applies to all accounts that had run previous versions
of McIDAS.  The only reason I commented on met171 is that is the only
one I saw.

re: We need to find out why /data3/mcidas keeps getting recreated and stop it.

>Well, I looked in the logs, I looked at the support email archives for info
>about STRTABLE (some other people out there are as confused as me even :),

Right, this stuff is pretty arcane.

>and  yet I have no idea where to go with this one. Any suggestions?

I poked around a little bit, but I could not make any headway since
I don't have logins as all of the users that might start McIDAS-X sessions.
My bet is that one user's setup is slightly off.  I thought that this
was probably that for the user running the LDM, but nothing jumped out
at me.  Closer examination may reveal the problem, however.

re: lots of email error messages
>It's a message about a cron job I have which checks for a failover site,
>thanks though, they are indeed error messages.....only about 1700 of them :)

Phew!  I knew there a lot, but I didn't look hard.

>later,

I will poke around more on Monday.  Have a good weekend.

Tom