Shared Memory and Semaphore Ids stored in Master Block error 1260

Shared Memory and Semaphore Ids stored in Master Block error 1260
Duplicate Shared Memory and Semaphore Ids stored in Master Block

As of Progress 8.0B the shared memory and semaphore id's are stored in the master block.

In Progress 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 of the database 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.

In the case of a crash, the next process which tries to open the database will read these shared memory and semaphore id's 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 database and shared memory.

If the shared memory segments are still in use, error 1260,  and sometimes followed by error 551 will result.

In order to restart the database, either wait until the shared memory is released by the processes still connected to it or identify these processes and send a SIGHUP or ENDTASK to them.  Article  How to find and remove invalid or orphaned Shared Memory using dbipcs and IPCRM.   

Then remove the shm and sem ids from the master block of the database. Methods of removing the shm and seg ids from the master block:

- PROUTIL -C truncate the bi file (Progress 8.0B and above)
- PROREST the database (Progress 8.2 and above)
- PROSTRCT repair (Progress 8.2 and above **)
- Run a single-user session then exit prior to starting the multi-user session.

** PROSTRCT repair can be used on a single volume database by simply typing "prostrct repair dbname" with no structure file available.