Details how progress handles :
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?
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..
