20050404: McIDAS and xvfb dispyay windows

>From: "Paul L. Sirvatka" <address@hidden>
>Organization: COD
>Keywords: 200504042331.j34NV1v2029887 McIDAS XWindows

Hi Paul,

>We have been having a lot of our scripts apparently crash our servers and
>are having a trouble of a time finding out why. There seems to be no
>reason and so perhaps you might have some insight.

OK.

>Many of the images we want are created by script with mcidas commands
>using the .k convention. We usually establish the session with a kickoff
>script to establish the environment.

OK.  You realize that McIDAS does _not_ need an Xserver to load images
and create raster pictures (e.g., GIF, JPEG, etc.).  Instead, McIDAS
frames are actually sections in a shared memory segment.  When one runs
an interactive McIDAS session, s/he is running an application, mcimage,
to "look at" (visualize) the information that has been loaded into a
frame.

>Now, we believe the problem stems from the xvfb which somehow crashes the
>server...the load gets unbearably high. For our gempka scripts, there is a
>switch for -display to tell which window number to run in. Is there such a
>convention for the micidas shells also?

You don't need and shouldn't use xvfb for your McIDAS scripts.
Instead, the scripts rely on the creation of a shared memory segment by
the application 'mcenv'.  All scripted McIDAS commands should run in a
'session' created by 'mcenv'.   For the "files", the setup in a
scripted McIDAS 'session' will look like:

1) define environment variables needed/used by McIDAS: MCHOME, MCDATA,
   MCPATH, PATH, and possibly MCTABLE_READ, MCTABLE_WRITE, and LD_LIBRARY_PATH

2) run 'mcenv' specifing frame specific information (e.g., number and size
   of frames created; number of image color levels, and number of graphic
   colors

3) run all desired McIDAS commands withing the session created by 'mcenv'
   including saving a raster represntation in the desired format using
   frmsave.k.

4) exit

Quick example:

#!/bin/sh

MCHOME=/home/mcidas
MCDATA=$MCHOME/workdata
MCPATH=$MCDATA:$MCHOME/data:$MCHOME/help
MCGUI=$MCHOME/bin
MCTABLE_READ='$MCDATA/MCTABLE.TXT;$MCHOME/data/ADDESITE.TXT'
MCTABLE_WRITE=$MCDATA/MCTABLE.TXT
PATH=${MCGUI}:$PATH
LD_LIBRARY_PATH=/usr/local/lib:/lib:/usr/lib

export MCHOME MCDATA MCPATH MCGUI MCTABLE_READ MCTABL_WRITE PATH LD_LIBRARY_PATH

cd $MCDATA

mcenv -f 5@600x800 -i 128 -g 32 << EOF

imgdisp.k RTIMAGES/GE-IR STA=KIAD MAG=2 EU=IMAGE GRA=1
map.k H GRA=1
frmsave.k 1 example_image.gif

end


In this example, a shared memory segment is created in a 'session'
created by 'mcenv' and all McIDAS commands are run in that 'session'.
An image is 'displayed' (nothing is visualized); a map is drawn; and
then the raster is saved in the file $MCDATA/example_image.gif.  At no
time is X involved, so xvfb should not figure into the picture.

One thing that can happen if the shell scripts are not complete (i.e.,
if all needed environment variables have not been defined and exported)
is that the invocation will fail at some point, and the 'session' will
not be exited cleanly.  When that happens, a shared memory segment will
be left over -- a situation that is not good.  In this case, the shared
memory segment must be cleaned up and the subdirectory that
corresponded to the 'session' under ~/.mctmp must be removed along with
all of its contents.

To check if you have left over shared memory segments, use the Unix
'ipcs' command:

ipcs

If you see a long list of shared memory segments owned by the user
running the scripts, you will have located the cause of your failures.
In this case, you have two choices to recover:

- use 'ipcrm' to remove the orphaned shared memory segments (e.g.,
  'ipcrm -m seg#') and 'rm -f' to remove the subdirectories of ~/.mctmp

- reboot

In cases when there are a LOT of orphaned shared memory segments, it
may be simplest to simply reboot.

>I hope this makes sense.

I think I understand your dilemma.  However, since McIDAS doesn't use
the X server (or virtual X server xvfb), the problems you are seeing is
not likely caused by it interacting with the X server.  Orphaned shared
memory segments, on the other hand, can happen and so must be addressed
in the manner I outlined above.

Cheers,

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.