Progress Database

How to Fix OpenEdge Progress DB Error 1260

If Progress says "Shared memory in use" but the database server is not running, old Linux processes may still be attached to the database memory. This guide shows a safe way to find them and restart the database.

The Problem

This usually happens after a crash, power issue, or unclean shutdown. For example, you may try to stop a database named sportsdb:

proshut /usr/wrk/sportsdb

Progress may reply:

There is no server for database /usr/wrk/sportsdb. (1423)

But when you start it again, you may see:

proserve /usr/wrk/sportsdb -S 9090
Shared memory in use by another process. (1260)

Why It Happens

OpenEdge Progress uses Linux shared memory while the database is running. If the main database broker stops badly, some helper processes, like _sqlsrv2, can stay alive. These old processes keep the memory busy, so Progress blocks the restart to protect the database.

Step 1: Check the Main Broker

First check whether the Progress broker is still running:

ps -ef | grep _mprosrv

If you see other databases, do not touch them. Only work with the database that has the problem.

Step 2: Read the Database Log

Check the last lines of the database log:

tail -100 /usr/wrk/sportsdb.lg

Look for shutdown messages, shared memory messages, or SQL server messages. The log usually tells you what happened before the error.

Step 3: Check Shared Memory

List Linux shared memory segments:

ipcs -m

If you see a segment with status dest and nattch greater than zero, Linux is waiting for attached processes to let go of that memory.

Step 4: Find the Process IDs

Check who created and last used the memory segment:

ipcs -m -p

Then find processes still attached to deleted shared memory:

for p in /proc/[0-9]*; do
    grep "SYSV00000000" $p/maps 2>/dev/null | grep deleted &&
    echo "PID=${p##*/}" &&
    ps -fp ${p##*/}
done

In many cases, the remaining processes are old _sqlsrv2 processes.

Step 5: Stop Only the Stale Processes

Before killing anything, confirm that the database lock file is gone and the main broker is not running:

ls -l /usr/wrk/sportsdb*

If you have confirmed the old process IDs, stop them gently:

kill -15 330 333 7687 9256

Use kill -9 only as a last option. Do not run ipcrm blindly on a server with more than one Progress database.

Step 6: Restart and Test

Start the database again:

proserve /usr/wrk/sportsdb -S 9090

Then check that it is running:

ps -ef | grep sportsdb
tail -50 /usr/wrk/sportsdb.lg

If you use ODBC or JDBC, test the connection after the broker and SQL server start correctly.