Status: Verified
GOAL:
What signals does the Progress / OpenEdge client and AppServer agent recognize?
GOAL:
What signal should be sent to generate a protrace file?
GOAL:
What signal should be sent to cause a progress client to dump core?
GOAL:
Is it all right to send the signal 8 or 16 to a Progress process?
GOAL:
What are Unix signals?
GOAL:
What is signal handling?
GOAL:
What command should be used to send a signal?
FACT(s) (Environment):
UNIX
Progress 9.x
OpenEdge 10.x
FIX:
The signals that are most used to control a Progress / OpenEdge client or AppServer agent are defined below. The command to send a signal to a process is:
kill -<signal> <pid>
For example: kill -TERM 1234
Note: do not use numeric signal numbers. Different Unix systems may have different numbers for the signal name. The semantics / behavior is linked to the name, not the number.
Description of signals
The following signals are (relatively) frequently encountered with Progress / OpenEdge processes:
- SIGTERM: request the running process to terminate normally. The signal can be sent by a user or another process. The Progress / OpenEdge process defines a special signal handler that will treat the signal as a QUIT statement.
- SIGHUP: indicate to the running process that the terminal it is trying to read or write to has disconnected. The signal is sent by the operating system as a response to a read or write operation. The Progress / OpenEdge process defines a special signal handler that will treat this as an untrappable STOP condition.
- SIGUSR1: request the running process to create a "protrace" file with a stack trace of the current execution point. The signal can be sent by a user. Execution continues unaltered. This is a specific Progress / OpenEdge feature.
- SIGABRT: request the running process to abort and create a "core" file with a memory image of the running process. This signal can be sent by a user or a debugger. The Progress / OpenEdge process defines a special signal handler that will try to dump a "protrace" file as well.
- SIGKILL: request the operating system to forcefully terminate the process. This signal can be sent by a user or another process. The operating system handles the termination, and the process cannot define any signal handler nor perform any "cleanup" before being terminated.
- SIGSEGV: this is generated by the operating system when the process is attempting to access an invalid area in memory. This indicates a bug or otherwise some kind of memory corruption. This signal is sent by the operating system. The Progress / OpenEdge process defines a special signal handler that will dump a "protrace" file and terminate the process unconditionally.
Context: what are signals?
on Unix, it is possible to send an asynchronous message called a "signal" to a running process. The behavior of the process depends on the signal and the signal handling routines that have been set up.
Some signals are triggered and sent automatically by the operating system depending on environment events. For example, SIGFPE (Floating Point Exception) is sent to the process automatically when it performs a divide error. SIGBUS (Bus error) is sent to the process automatically when it tries to access a badly constructed address in memory, or using an invalid address mode. SIGSEGV is sent when the process tries to access an area of memory where it does not have access to.
Some signals can be triggered by the process itself for some functional purpose. For example, a process can set up a timer to deliver SIGALRM after a delay. This can be used for example to delay an operation or the output of some information. Or a process can ask the system to send SIGIO to itself when some data becomes available on an open file handle.
Some signals exist for the purpose of providing a communication mechanism with other processes. For example SIGPWR is "reserved" to the driver process of power management units, to handle events with the external power source. Two signals are "reserved" for inter-process communication, with no predefined meaning: SIGUSR1 and SIGUSR2./STRONG>
Many signal names are defined and specified in the POSIX standard. Most Unix systems share the same behavior and semantics for a large number of signal names.
Context: how does it work?
Signals are numeric messages that are sent from one process (or the operating system) to another process or process group.
When a process "receives" a signal, one of either two things can happen:
- either the process has defined a custom signal handler, in which case execution will be suspended and the signal handler will start execution, or
- the process has not defined a custom signal handler, in which case the default behavior prevails.
The default behavior depends on what signal is being sent. Here are some common default behaviors:
SIGHUP (terminal disconnects): terminate the process
SIGINT (Ctl+C): undo the current transaction, but continue the session
SIGQUIT (Ctrl+\): terminate the process
SIGILL (illegal instruction): terminate the process and dump core
SIGABRT (abort execution): terminate the process
SIGFPE (floating point exception): terminate the process and dump core
SIGKILL (terminate forcefully): terminate the process. This signal is always handled by the operating system and is not delivered to the process.
SIGSEGV (invalid memory reference): terminate the process and dump core
SIGBUS (invalid address): terminate the process and dump core
SIGPIPE (broken pipe): signal passed to the program issuing the write call to handle
SIGTERM (terminate process): terminate the process
SIGUSR1 (user defined signal 1): create a protrace file and continue
SIGUSR2 (user defined signal 2): terminate the process
SIGCHLD (a child process has terminated): signal is ignored
SIGSTOP (suspend execution): process is stopped. This signal is always handled by the operating system and is not delivered to the process. Execution is resumed when SIGCONT is sent.
SIGCONT (continue execution): signal is ignored. Operating system resumes execution of the process if previously stopped.
The Progress / OpenEdge client defines a custom signal handler for several of these signals. The signal handler either causes the ABL client to terminate normally (and close open database connections) or abnormally, in which case a "protrace" file is also created.
Note: because the signal SIGKILL is handled by the operating system and the process (the Progress / OpenEdge client) never gets a chance to "react" to it, it should be considered as dangerous: in case of database connections the client may not get a chance to release shared resources and the database could be left in an abnormal state -- causing an abnormal shutdown of the server and other clients afterwards..