Feedback
Did this article resolve your question/issue?

   

Article

How Progress interprets and handles kill Signals

« Go Back

Information

 
TitleHow Progress interprets and handles kill Signals
URL NameP67938
Article Number000169313
EnvironmentProduct: Progress
Product: OpenEdge
Version: All supported versions
OS: All Supported Operating Systems
Question/Problem Description
How Progress interprets and handles kill signals?
How Progress handles signals?
How Progress handles of signals for both local and remote client connections and servers?
What is the meaning behind the numeric signal value?
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
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 of signals and how they are handled by the client and the server.
The signals listed below are programmatically handled by the OpenEdge client (_progres, prowin32, prowin) and AppServer agent (_progres, proapsv) C/C++ executables.  These signals will often not be handled gracefully by Java which has different signal handling rules.
 
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 sub process 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 sub processes 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
 
Signal Name: SIGUSR1
Common Signal Number: Linux: 10, Solaris and HPUX: 16, AIX:  30
Considered by Progress: HANDLED
Client Handling: dump core without termination
Server Handling: dump core without termination
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
When 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 the following effects on Progress Client and Server:
 
These signals cannot 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 cannot 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.
Workaround
Notes
Last Modified Date11/20/2020 7:14 AM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.