>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 'address@hidden mccheck' to: #-c 'address@hidden 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
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.