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

20010510: Error creating shared memory segment on Linux (cont.)

>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