Kbase P67938: How Progress interprets and handles kill Signals
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
01/10/2009 |
|
Status: Verified
GOAL:
How Progress interprets and handles kill signals
GOAL:
How Progress handles signals
GOAL:
How Progress handles of signals for both local and remote client connections and servers
GOAL:
What is the meaning behind the numeric signal value?
FACT(s) (Environment):
All Supported Operating Systems
FIX:
When a kill signal is sent to a process the process may have a programmed method of responding to the signal. If the process does not have a method defined for dealing with specific signals the operating system will take some default action on behalf of the process which receives the signal. Progress may tell the operating system that it will ignore certain signals. If the signal is passed to Progress, then depending on what signal is sent different actions may be taken (i.e. ignore, process as a fatal exception, disconnect, etc.).
How many signals there are depends on the Operating System. Below is a list signals and how they are handled by the client and the server.
Signal Name: SIGHUP
Common Signal Number: 1
Considered by Progress: HANDLED
Client Handling: 1) write message to .lg that HANGUP signal rcvd, 2) ignore any additional SIGHUP, 3) if in UNIX escape then wait for subprocess to complete before exiting
Server Handling: 1) IGNORED for SERVER, 2) IGNORED if forked process, 3) NOT IGNORED if in UNIX escape
Signal Name: SIGINT
Common Signal Number: 2
Considered by Progress: HANDLED
Client Handling: 1) IGNORED if in UNIX escape, 2) IGNORED by forked process, 3) If screen exists perform some screen cleanup
Server Handling: IGNORED by forked process
Signal Name: SIGQUIT
Common Signal Number: 3
Considered by Progress: HANDLED
Client Handling: write message to .lg that kill signal rcvd
Server Handling: 1) IGNORED for SERVER, 2) IGNORED if forked process, 3) IGNORED if in UNIX escape
Signal Name: SIGILL
Common Signal Number: 4
Considered by Progress: Fatal
Client Handling: Standard Fatal see Below
Server Handling: Standard Fatal see Below
Signal Name: SIGFPE
Common Signal Number: 8
Considered by Progress: Fatal
Client Handling: Standard Fatal see Below
Server Handling: Standard Fatal see Below
Signal Name: SIGKILL
Common Signal Number: 9
Considered by Progress: REALLY Fatal
Client Handling: REALLY Fatal see Below
Server Handling: REALLY Fatal see Below
Signal Name: SIGBUS
Common Signal Number: 7 & 10
Considered by Progress: Fatal
Client Handling: Standard Fatal see Below
Server Handling: Standard Fatal see Below
Signal Name: SIGSEGV
Common Signal Number: 11
Considered by Progress: Fatal
Client Handling: Standard Fatal see Below
Server Handling: Standard Fatal see Below
Signal Name: SIGSYS
Common Signal Number: 12
Considered by Progress: Fatal
Client Handling: Standard Fatal see Below
Server Handling: Standard Fatal see Below
Signal Name: SIGPIPE
Common Signal Number: 13>Considered by Progress: HANDLED
Client Handling: 1) if writer wants to process broker pipe then return, 2) look for valid output stream to write broken pipe message 3) look for dead subprocesses and attempt to close
their file descriptors
Server Handling: 1) IGNORED by forked process, 2) If screen exists perform some screen cleanup write message that signal received
Signal Name: SIGTERM
Common Signal Number: 15 (this is the default signal sent by kill with no args)
Considered by Progress: HANDLED
Client Handling: 1) IGNORED if forked process, 2) IGNORED if in UNIX escape, 3) rest is same as SIGQUIT
Server Handling: 1) write message to .lg that SIGTERM signal rcvd, 2) initiate shutdown
Signal Name: SIGPWR
Common Signal Number: 19
Considered by Progress: IGNORED
Client Handling: IGNORED
Server Handling: IGNORED
Signal Name: SIGWINCH, SIGWINDOW, SIGWIN
Common Signal Number: 20 (may not exist or may vary depending on system)
Considered by Progress: IGNORED
Client Handling: IGNORED
Server Handling: IGNORED
Signal Name: SIGSTOP
Common Signal Number: 23
Considered by Progress: REALLY Fatal
Client Handling: REALLY Fatal see Below
Server Handling: REALLY Fatal see Below
Signal Name: SIGTSTP
Common Signal Number: 24
Considered by Progress: IGNORED
Client Handling: IGNORED
Server Handling: IGNORED
Signal Name: SIGCONT
Common Signal Number: 25
Considered by Progress: HANDLED
Client Handling: if environment for PROSIGTRACE=1 then prints the OS signal methodology (sigaction or signal)
Server Handling: if environment for PROSIGTRACE=1 then prints the OS signal methodology (sigaction or signal)
Signal Name: SIGTTOU
Common Signal Number: 27
Considered by Progress: IGNORED
Client Handling: IGNORED
Server Handling: IGNORED
Signal Name: SIGXCPU
Common Signal Number: 30
Considered by Progress: Fatal
Client Handling: Standard Fatal see Below
Server Handling: Standard Fatal see Below
Signal Name: SIGXFSZ
Common Signal Number: 31
Considered by Progress: Fatal
Client Handling: Standard Fatal see Below
Server Handling: Standard Fatal see Below
Signal Name: SIGDANGER
Common Signal Number: 33
Considered by Progress: HANDLED
Client Handling: write message low system resources
Server Handling: write message low system resources
Signals not defined above are typically ignored or aliased to SIGHUP. As a general rule, all signals not listed above which have a default behavior of disconnecting or generating a core will typically be aliased to SIGHUP and will follow the rules listed above for SIGHUP.
STANDARD FATAL has the following effects on Progress Client and Server:
Write the appropriate message to the .lg file (if it is open when the signal is received).
close files
reset/restore terminal settings
close connection to database (if connected)
dump core
close temporary files
free memory/stack
exit
Be aware that if a process connected to shared memory dies while in a critical phase it can lead to the Broker shutting down the database to preserve database integrity. Typically this occurs if the shared memory connected process died holding a shared resource (buffer, lock, latch, semaphore), the broker will shut down the database to preserve database integrity.
REALLY FATAL has th.e following effects on Progress Client and Server:
These signals can not be caught, blocked or ignored by Progress. Although these signals provide a definite way of killing a process it is recommended that these never be used to remove a Progress process (or only as an absolute last resort) as the process is removed by the operating system.
The effect on Progress if a REALLY FATAL signal is sent to client or server:
Any shared resources owned by that process can not be released
If the process was updating shared memory structures when the signal was sent and the operation did not complete then these shared memory structures are corrupt
When such a case is noticed by the database manager via the Progress Watchdog then the database will be shutdown to avoid writing this corruption to disk
If a client is connected remotely and the client is issued a fatal signal the client will die but the remote server will not die. The remote client server should perform all necessary tasks to clean up for the dead client..