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

20030313: McIDAS unable to start at CCNY

>From: "Kwan-yin Kong" <address@hidden>
>Organization: CCNY
>Keywords: 200303131908.h2DJ8IB2013411 McIDAS shared memory

Hi Kwan-yin,

>There was an error on McIDAS that came suddenly yesterday 
>afternoon which prevented mcidas to run correctly here at 
>CCNY.  The symptoms are these:
>1.  When `mcidas' is issued at the terminal, the error 
>message [mcenv: Cannot make positive UC: could not create 
>1049900-byte shared memory segment] appears and mcidas 
>fails to start all together.

Since McIDAS was working, I am willing to bet that your
system ran out of shared memory segments.  This is likely due
to incorrect exiting of McIDAS and/or McIDAS processes.  The
cleanup solution is to:

1) shut down any running McIDAS-X applications

2) remove hidden directories created for McIDAS sessions/processes

   cd ~/.mctmp
   rm -rf *

3) remove shared memory segments that are left on the system.  This
   is a two stage process:

   o find the IDs of the shared memory segments using 'ipcs'
   o remove the shared memory segments using 'ipcrm'
   I am assuming that the system you are working on is Linux, so the
   following is the syntax for using 'ipcrm' on Linux:


------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 270041105  mcidas    600        384300     1                       
0x00000000 270073874  mcidas    600        512000     0 

ipcrm -m 270041105
ipcrm -m 270073874

    run the 'ipcrm -m' invocation for each shared memory segment owned
    by the user

4) if your are running the LDM on this same machine, and it is running
   the McIDAS-XCD decoders, you may have to do the same thing for
   the 'ldm' account as for the other account(s): repeat steps 1-3

Once the shared memory segments are cleaned up, you should stop having
problems running McIDAS.
>2. When `mcidasx' is issued at the terminal, mcidas is 
>able to start but it cannot load any images from ADDE. 

All bets are off until you clean up the shared memory segments.

The other way to get rid of the shared memory segments (after
you delete the hidden directories under as per 1) above) is
to reboot.

> But it CAN load images that have been saved locally.  In 
>addition, when I tries to change the ADDE locations (using 
>the DATALOC command), it fails and reports that it is 
>probably due to incorrect setup.
>Before this problems occurred yesterday afternoon, I was 
>helping Prof. Hindman on a dry-run of a mcidas exercise 
>for a student lab.  The only thing I did was to change the 
>mcidas/data directory in the user account to be read-only 
>in order to prevent students accidentally deleting the 
>saved images.  Later I changed the images themselves to be 
>read-only, but the mcidas/data directory back to writable.
>Do you recognize what the problem(s) may be?  I appreciate 
>your help again.

Check the shared memory as I indicate above, and let me know if
that doesn't solve your problem.


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.