Kbase P3811: Shared Memory and Semaphore Ids stored in Master Block error 1260
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
12/16/2008 |
|
Status: Verified
SYMPTOM(s):
Shared Memory and Semaphore Ids stored in Master Block error 1260
Duplicate Shared Memory and Semaphore Ids stored in Master Block
Shared memory in use by another process. (1260)
SYSTEM ERROR: unable to <acc/cr> semaphore set <db>:<ch>, errno 22. (551)
FACT(s) (Environment):
Progress 8.0B
Progress 8.1x
Progress 9.x
OpenEdge 10.x
All Supported Operating Systems
CHANGE:
As of Progress 8.0B the shared memory and semaphore id's are stored in the master block. In 8.0B, the system ftok() function was no longer used to generate shm and sem ids. Shm and sem id's are now requested with a generic unique key which tells the system only to provide unique id's or else fail. This required that the shm and sem id's for the database are stored in the master block in order to provide a safe, known location for clients to find these id's. These holders in the master block are cleared as part of normal shutdown.
CAUSE:
In the case of a crash, the next process which tries to open the database will read these values, to see if they still exist on the system. If they are, it will see if the shared memory is still in use (it is a check which looks to see if any processes are still attached to the shared memory).
If no processes are still attached, then the "old" shared memory and semaphore set is cleaned up and the holders in the master block are reset. If there are still processes attached to shared memory, the restart fails in order to protect the integrity of the database. Eventually, the processes attached to the shared memory detect the death of the server, and disconnect from the db and shared memory.
If the shared memory segments are still in use, error 1260, followed by error 551 will result.
FIX:
In order to restart the database, either wait until the shared memory is released by the processes still connected to it, or else remove the shm and sem ids from the master block of the database. Refer to solution 15912 for information on checking the shared memory segments.
Possible ways of removing the shm and seg ids from the master block.
- truncating the bi file (Progress 8.0B and above)
- prorest the database (Progress 8.2 and above)
- prostrct repair (Progress 8.2 and above)
- Running a single-user session and exiting prior to starting the multi-user session (pre Progress 8.2)
Note: The prostrct repair can be used on a single volume database by simple typing "prostrct repair dbname" with no structure file available.