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.