The preferred method of stopping a process connected to a database, is to disconnect the user through PROMON or the PROSHUT -C disconnect <usernumber>.
Similarly, the Database Broker should be stopped with OpenEdge command line (proshut, dbman, asbman etc) or through the OpenEdge GUI Console.
There are times however when a process is not responding and needs to be terminated. The following is a guideline for using the UNIX kill command
to cancel a defunct process or to release shared memory.
1. Confirm/Find the process's pid:
$ ps -ef | grep [process]
2. Issue these kills as root in the following order until the process is killed
- (SIGHUP) terminal hang up signal: $ kill -1 <pid>
- (SIGINT) equivalent to a Ctrl+C, terminal interrupt: $ kill -2 <pid>
- SIGTERM) default if unspecified is a software termination likely to release the lock and shared memory being held. If the process is using CPU time, a kill -15 will generate a core file. A debugger will then be used to generate a stacktrace of the process. Articles How to produce a readable text file from a core file that is created as a result of a Progress system error? and How to use dbx to obtain a stack trace when no core is dumped describe how to use debuggers that are most commonly found on UNIX systems: $ kill -15 <pid>
- (SIGFPE) won't free the lock but produces a memory dump named core in the directory in which the session was started: $ kill -8 <pid>
- (SIGKILL) which 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 000012575 to check on active message queues, memory, and semaphores): $ kill -9 <pid>
- If the process does not respond to SIGKILL, the server will need to be rebooted
Considerations:For detailed clarification on unix kill signals, refer to Article:
How Progress interprets and handles kill Signals kill USR1: Will not kill the process, but should produce a core file and a protrace. The protrace can be useful for Progress techsupport in debugging issues. Excercise caution using this method in OpenEdge versions that have not had async unsafe signal handling addressed. Refer to Article
Can KILL -SIGUSR1 cause a process to crash? kill -8 or kill -9: When the process which is connected to the shared memory of a database may cause the database to shut itself down to preserve integrity if a lock, latch, or buffer is held by the process that was killed.
kill -9: Otherwise known as
"throwing the big red switch".
- UNIX does not allow any program to detect a SIGKILL. The Database Manager server processes cannot detect what is happening when shared-memory connected processes start to disappear with kill -9. Depending on the which process is killed off and what the process is doing, the database manager may detect that the process was holding locks in shared memory and is likely to bring the database down, by design. Furthermore, when enough processes are serially killed off, remaining processes can effectively "hang" and cannot be disconnected either since when they are waiting for some resource that will never be released by a lost process.
- Using SIGKILL is not a good idea since most systems with buffered filesystems can get into real trouble. In some cases it is better to perform a clean reboot of the system than to start randomly killing processes.
- For further discussion refer to Article Considerations when using the UNIX kill -9 command
PROSHUT While PROSHUT is the preferred method, when issued shutdown is not instantaneous. With many users, any active transactions need to be backed out before the disconnect of connected processes occurs. This is typically when production environments start using KILL signals, which interferes with the shutdown routine.
Shutdown improvements were enhanced in OpenEdge 10.2B in order to assure as much current shared-memory transaction activity is committed or undone before shutdown as opposed to being resolved during the BI recovery phase at startup which requires all this information to be read from disk (as opposed to most this information already having being read in shared-memory). The shutdown improvements also introduced a configurable
-shutdownTimeout parameter to limit the 10 minute default time period the PROSHUT process will wait for the database activity to end. Understanding specific environment reasons is outlined in the following Article
Investigating why the database takes so long to shut downIf a forced shutdown (proshut -F) issued after a graceful shutdown does not seem to work and you are not comfortable isolating and killing remaining processes then finally cleaning up shared memory before re-starting, then reboot the system.
