>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.