Shared Memory client connects to the wrong database after power failure or abnormal shutdown

When all the following are true, a shared-memory client (e.g. mpro , probkup online) will connect to the wrong database:

• Multiple databases are running on a server
• All databases abnormally shutdown leaving the .lk file behind after a system outage
• Not all databases are restarted multi-user
• One of the databases starts with the shared-memory identifier that a database that was not started previously used

The following VST from the connected client confirms extents paths of the wrong database
 

DISPLAY pdbname(1) FORM "X(60)".  /* the mpro dbname in the connection */
FOR EACH _AreaExtent NO-LOCK with NO-BOX:
DISPLAY _Extent-path FORM "X(80)". /* the extent paths to the wrong database  */
END.

Being able to connect to another database is a security issue, when all databases are on the same machine. 
Being able to connect to the wrong database can cause irrecoverable application data loss when the client is running QA or development test code against a production database.

Shared-memory clients do not verify at connection time for database names including paths in addition to the database's shared memory ID and semaphore ID to avoid this situation.  The connection should fail with the "There is no server for database (1423)" error, but because this check is missing in the product, a shared memory client is able to attach to the shared memory of another running database.

• When more than one database is started and the system crashes the shared memory ID (segment_id) remains in the master block (this is not true for any other case like normal or abnormal shutdown)
• After the machine is rebooted, when databases are started and the new segment_id assigned by the OS to one of the databases matches the old segment_id of a database that has not yet started and therefore still has this same segment_id reference in its master block
• There is a check performed by the BROKER besides shared memory ID and semaphore ID, database names(including paths) to guarantee that the database is connecting to its shared memory and not another database's shared memory, but shared-memory clients do not run this check.

Upgrade to OpenEdge 11.7.4 Service Pack or later where the defect OCTA-4036 is fixed.

An additional check when shared-memory connect to a database, for database names (including paths) in addition to the existing shared memory ID and semaphore ID verification.

As a consequence of this improvement, ensure that no symlinks are used in the databases path otherwise shared-memory clients will fail to connect with error 10834:
For further information refer to Article:

•  Shared memory connection to OpenEdge databases fails since upgrading to 11.7.4 error 10834  

To avoid this situation after a system outage, the following actions will clear the shared_memory identifier in the Master Block which need to be carried out against every database on the machine before re-starting any database: Option 1:  Start a single-user session against each database
Option 2:  Truncate the bi files of all databases, then start databases multi-user as required.   
Option 3:  Run PROSTRCT REPAIR on every database to clear the shared memory ID, then start databases multi-user as required

1. First verify that the database structure file (.st) is current listing full-paths to every database extent: $   prostrct list dbname dbname.st
2. Then run PROSTRCT REPAIR on every database to clear the shared memory ID: $   prostrct repair dbname dbname.st

Option 4:  Ensure all databases on the server have completed their bi crash recovery and have restarted,  before allowing any shared-memory connections.

 

Progress Articles:

 How to find and remove invalid or orphaned Shared Memory using dbipcs and IPCRM.   
 Unable to restart a database after power outage with error 1423