>From: "Wayne Bresky" <address@hidden> >Organization: Cornell >Keywords: 200105101312.f4ADCpp12063 McIDAS Linux shared memory Wayne, >Thanks for the quick response. No problem. >The output I showed you in my previous email came not from top, but >from typing 'ipcs -l' on the machine in question. Sorry for the confusion. I understood that the listing was not from 'top'. I was interested in what top actually had to say, but your follow-up information looks like the problem is elsewhere. >I was looking at the top output to see how much RAM was available. >And that output (not shown) showed a number larger than the number >of bytes in the error message. From this I assumed there was enough >memory, in general, to run McIDAS. Now onto the issue of shared >memory... I would assume the same. >I think you may be right about the shared memory. I was able to view output >from /proc/sys/kernel/shmmax on the machine that IS running McIDAS and I >see the following number: > >33554432 (I assume this is bytes) This is exactly the same number I get from my RedHat 6.2 Linux box at home (where I am answering this from): /proc/sys/kernel% cat shmmax 33554432 Looks like this is a fixed thing. >The same file does NOT exist on the machine where I am having the problem. >Would you agree that this file should exist? Yes, absolutely. It is very strange that this file does not exist. Not being a Linux expert, all I can offer is a list of the files that I find in the /proc/sys directory on my home machine and couple of other Linux machines at work: RedHat 6.2 (my home machine): /proc/sys/kernel% ls acct domainname osrelease printk rtsig-nr sysrq cap-bound hostname ostype real-root-dev shmall version ctrl-alt-del modprobe panic rtsig-max shmmax RedHat 7.0: /proc/sys/kernel% ls acct domainname osrelease printk rtsig-nr sysrq cap-bound hostname ostype real-root-dev shmall version ctrl-alt-del modprobe panic rtsig-max shmmax /proc/sys/kernel% cat shmmax 33554432 RedHat 7.1: /proc/sys/kernel% ls acct hotplug osrelease printk rtsig-nr sysrq cap-bound modprobe ostype prof_pid sem threads-max ctrl-alt-del msgmax overflowgid random/ shmall version domainname msgmnb overflowuid real-root-dev shmmax hostname msgmni panic rtsig-max shmmni /proc/sys/kernel% cat shmmax 33554432 Given that all three machines above have /proc/sys/kernel/shmmax files, and given that the files all contain the exact same number, I can only assume that this file (and perhaps others?) is missing from your machine. Is it possible that this machine has been broken into? Not that this file being missing tells me this; I just remember that Jim DeMarco told me one time that there was a history of Cornell Linux boxes getting broken into. re: was the machine rebooted after the shared memory configuration >Unfortunately, I cannot answer your question. The system administrator >for the machine in question left about a month ago, and I am his (confused) >replacement! I know Jim DeMarco, so I am aware of your (Cornell's) prediciment. >Is there a way to definitely determine whether or not shared >memory is "enabled". I assumed from the ipcs -l output that shared memory >was activated. But perhaps it is not. I will likely follow the >instructions from >the web page and reboot the machine. Sound like a logical thing to do? I can't answer the first question. I can suggest that following the web page advice and rebooting can do nothing but help. >Thanks again. Please let me know the results of the configuration/reboot. Tom >From address@hidden Thu May 10 12:47:21 2001 >Subject: Re: 20010510: Error creating shared memory segment on Linux (cont.) Tom, >I am happy to report that the reconfiguration and reboot worked >(option 1). I can now open a McIDAS session on the machine >in question. Excellent! >Thanks again for your help. Thanks for letting me know that the procedure was successful. 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.