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

20010510: Error creating shared memory segment on Linux



>From: "Wayne Bresky" <address@hidden>
>Organization: Cornell
>Keywords: 200105101312.f4ADCpp12063 McIDAS Linux shared memory

Wayne,

>site--Cornell University
>McIDAS coordinator--Mark Wysocki
>(I will soon be taking over the responsibility from Mark)

OK.

>Dee Wade has suggested I contact you regarding a problem I have been
>having running McIDAS on a Linux workstation.  Specifically, I have been
>getting the following error while trying to initialize McIDAS:
>
>'Cannot make positive UC: could not create 384300-byte shared memory'

This is interesting in that the size of the shared memory segment is
very small.  Usually, sites run into problems when they try to create
a McIDAS session with a lot of frames and they don't have enough shared
memroy.

>At first, I thought something was wrong with the MCPATH setting or maybe
>there wasn't enough memory to run McIDAS, but I have since ruled these =
>out
>as possible causes (after checking MCPATH and running 'top' to see how
>much memory was available).

MCPATH wouldn't come into this one.  I am suprised that your top invocation
shows that you do have enough shared memory.  A quick top on my RedHat 6.2
Linux machine shows:

  9:04am  up 1 day,  6:48,  8 users,  load average: 0.12, 0.20, 0.29
83 processes: 81 sleeping, 1 running, 1 zombie, 0 stopped
CPU states:  1.5% user,  4.0% system,  0.0% nice, 94.3% idle
Mem:   257720K av,  128564K used,  129156K free,   30248K shrd,   12244K buff
Swap:  273024K av,   81308K used,  191716K free                   57572K cached

It is important to note that shared memory will depend on physical
RAM and swap space.  You could setup a huge amount of shared memory
that would never be accessible if either of these (RAM/swap) was not
sufficient to support the use.

>The MUG help desk suggested the problem
>might be the result of insufficient shared memory.  I do not believe
>this to be
>the case.

I don't know what it would be otherwise.  The error message you sent
in is generated from code that tries to allocate shared memory.  The return
from the routine is checked, and a failure is reported.

>I say this, because the limits (shown below) are identical to
>the
>settings of a second machine that is running McIDAS without a problem.
>
>> ------ Shared Memory Limits --------
>> max number of segments 1024
>> max seg size (kbytes) 32768
>> max total shared memory (kbytes) 134217728
>> min seg size (bytes) 1

The number listed for total shared memory looks pretty big, but not
outrageous.  How much physical RAM and swap does this machine have?
How was shared memory configured on the system?

The very bottom of the web page:

http://www.unidata.ucar.edu/packages/mcidas/770/mcx/workstation.html

describes the two methods I know of for setting shared memory in Linux.
Was either of these procedures used to set shared memory on your machine?

>Is there anything you can suggest that might help solve this problem?

Nothing jumps out at me especially given your comment that there is
another machine identically configured that is not experiencing the
problem.  Also, given the very small size of shared memory indicated in
the error you sent a long, it is as though your machine can't allocate
any shared memory.  This is something that I have never run into.

The following is a foolish question, but I have to ask anyway.  Did you
configure shared memory and then not reboot for it to take effect (I
doubt this, but given that I have no ready answers for the problem you
are seeing, I have to ask).

>Thanks for your assistance.

Tom Yoksas


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.