Using kill -9 to terminate shared memory processesIt is never a good idea to "
throw the big red switch". Most systems with buffered filesystems can get into real trouble. UNIX does not allow any program to detect a SIGKILL, which means the database watchdog processes cannot detect what is happening when processes start to disappear at the system level with kill -9. In most cases it is better to perform a clean reboot of the system than to start randomly killing processes.
Depending on which process is killed off and what the process is doing, that session may very well have been holding a latch. PROGRESS will eventually detect this abnormality and trigger an Abnormal database shutdown the database. In other instances when enough processes are serially killed off, remaining processes can effectively "hang" as they could be waiting for some resource that will then never be released by a lost process.
If the database Broker process(_mprosrv) is killed with a SIGKILL( Kill -9), there will not be time for entries to be created in the database log file. This means that the .lg will not show any information about a shutdown or crash; activity in the database log will cease.
Using kill -9 on Unix systems:
$ kill -9 <pid>
Before sending the signal:
- Ensure the PID exists with: ps -ef | grep <pid> for example.
- Do not pass 1 as the PID, -1 is the “init” process.
- Ensure the PID has no children, this is often overlooked.
SIGKILL truly kills the process and requires the release of held semaphores and shared memory segments for both the user sessions and the broker process. Refer to Article:
If forcing the database to shutdown with:
proshut -byF does not work and you are not comfortable isolating and killing remaining processes then finally cleaning up shared memory before re-starting, then reboot the system.
For further information refer to Article
Guidelines on the use of UNIX kill command to stop a process 
