-
Title
Removing shared memory segments in Linux -
Description
A customer experiences the following error when starting cop:
[ILUV shareplex] $ ./sp_cop -u2600 &
[1] 1161
[ILUV shareplex] $ can't setup shared memory statistics capability - exiting -
Cause
SharePlex was forced to shutdown or normal shutdown was not successful, or any other reason by which some of SharePlex processes are not killed .
-
Resolution
To resolve this issue, perform the following in the $SP_SYS_VARDIR/rim directory:
od -x shmaddr.loc
od -x shstinfo.ipc
This will generate a set of numbers, like below:
$ od -x shmaddr.loc
0000000 0012 006d e000 f635 9640 001a 7000 0001
0000020 8024 01fc
0000024
$ od -x shstinfo.ipc
0000000 8007 006c a000 f64c 9640 000a 0000 0080
0000020 0023 01fc
0000024
You can remove shared memory segments by looking at the 6th set of numbers on the od -x output. For example, the 6th set of numbers from above was: 9640. You will then do an ipcs -a | grep 9640 command to get the list of shared memory segments. This will give you an output like the following:
$ ipcs -a | grep 9640
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x001a9640 7143442 oracle 644 94208 0
0x003a9640 7176211 oracle 644 33554432 0
0x004a9640 7208980 oracle 644 8388608 0
0x005a9640 7241749 oracle 644 8388608 0
------ Semaphore Arrays --------
key semid owner perms nsems
0x000a9640 33292323 oracle 666 12
0x001a9640 33325092 oracle 666 26
------ Message Queues --------
key msqid owner perms used-bytes messages
You will then need to use the ipcrm command to remove the unwanted memory segments. In this example, you would do the following:
Note this will need to be done as root
$ ipcrm -m 7143442
$ ipcrm -m 7176211
$ ipcrm -m 7208980
$ ipcrm -m 7241749
$ ipcrm -s 33292323
$ ipcrm -s 33325092
and check back to see that they are cleared by issuing ipcs -a grep <6th entry>
You should then be able to start cop.Additional Information:
It has been observed that yet another falvor of Linux (RH 3.0) may give out a slightly different output for ipcs -a. For example, in another situation, the od-x was as follows:
[oracle@DTEIUC2-1pub rim]$ od -x shmaddr.loc
0000000 8008 003d 6000 41a5 1753 0011 7000 0001
0000020 800b 0028
0000024
[oracle@DTEIUC2-1pub rim]$ od -x shstinfo.ipc
0000000 0007 003d 6000 4125 1753 0001 0000 0080
0000020 000a 0028
0000024and the ipcs | grep 1753 output was:
[oracle@DTEIUC2-1pub rim]$ ipcs -a | grep 1753
0x00011753 4227079 root 644 8388608 0
0x00111753 4259848 root 644 94208 0
0x00311753 4292617 root 644 104857600 0
0x00411753 4325386 root 644 104857600 0
0x00511753 4358155 root 644 104857600 0
0x00611753 4390924 root 644 104857600 0
0x00011753 2719754 root 666 12
0x00111753 2752523 root 666 26From the above it was observed that though there was no separate heading for semaphore or shared memory entries, the fourth field contained a slightly different value (most likely some permission). So in case of shared memory it was 644 whereas for semaphores it was 666.
So the following were used to remove the hung shared memory and semaphores:
ipcrm -m 4227079
ipcrm -m 4259848
ipcrm -m 4292617
ipcrm -m 4325386
ipcrm -m 4358155
ipcrm -m 4390924
ipcrm -s 2719754
ipcrm -s 2752523 -
Additional Information
For some flavors of linux ipcs -ma works at times instead of ipcs -a..