White Papers
Abstract
Signals are used for interprocess communication. For problem determination, it is often helpful to send signals to the WebSphere processes.
Content
Q: What is a signal?
A: A signal is a runtime exception from operating system native code.
Q: What are commonly used signals?
A: SIGQUIT, SIGSEGV, SIGKILL, SIGTERM, SIGILL are often discussed in WebSphere documentation and problem determination documents. Programs may be written with a signal handler to handle some of these signals. Others are only handled by the operating system.
SIGQUIT = quit, generated from terminal special char. This signal usually does not terminate the running process.
SIGSEGV = segmentation violation
SIGKILL = kill (cannot be caught or ignored).
SIGTERM = software termination signal
SIGILL = illegal instruction
Q: Why can we change the behavior of some signals, but not others?
A: Some signals are handled by user programs (e.g., SIGQUIT) and have a default behavior. Most programs include signal handler code to be invoked when the process receives this signal.
Other signals are handled by the operating system. In other words, they can't be masked or altered by the program.
Q: Where are the defined signals listed?
A: While the signals are compiled into programs, the source files are typically included in the operating system. The default location is /usr/include/signal.h. In most operating systems, this file includes /usr/include/sys/signal.h. This second file contains the actual definitions.
Q: How does Java handle signals?
A: What Java does with a particular signal is determined by the signal handler in place for java. For the common signal listed, here is what the signal frequently is indicative of:
| Signal | ||
| SIGQUIT | generated by a kill -3 on the java pid. This signal does not terminate the running process. |
|
| SIGSEGV | Typically, this is caused by an error in native code. It frequently indicates a bug in the native library that generates it. |
|
| SIGKILL | Typically, this is due to a command done by a system admin or cron job. | This terminates the java process without dumping any thread dumps (javacore, etc) |
| SIGTERM | Typically, this is generated by a native library. | This terminates the java process. This would typically come from a signal handler after it has handled a signal. |
| SIGILL | Typically, this is caused by a stack overflow or jit compiler problem. |
1. disable the jit compiler 2. use the jit debug steps 3. try skipping the method that is being jit compiled. |
| SIGBUS | Typically, this is caused by a running program. | This is sometimes caused by the older jdbc drivers that were a combination of both java and native code. |
| Signal | Description | JVM Action |
| SIGUSR1 (SIGJVM1) | User Signal 1 | Suspends threads doing GC |
| SIGUSR2 | User Signal 2 | Used by JIT |
| SIGFPE | Floating Point Exceptn | javacore and abort |
| SIGSEGV | Segmentation Violation | javacore and abort |
| SIGILL | Illegal Instruction | javacore and abort |
| SIGABRT | Abort | javacore and abort |
| SIGBUS | Bus Error | javacore and abort |
| SIGEMT | Emulator Error | javacore and abort |
| SIGSYS | Bad Arg to sys call | javacore and abort |
| SYSXCPU | CPU time limit exceeded | javacore and abort |
| SIGXFSZ | File Size limit exceeded | javacore and abort |
| SIGQUIT | Quit | javacore and continue |
| SIGPIPE | Broken Pipe | Ignored |
| SIGTERM | Terminate process | |
| SIGKILL | Kill process | None |
| SIGTRAP | Trap | None |
| SIGALRM | Alarm | None |
| SUGURG | ||
| SIGSTOP | Stop | None |
| SIGTSTP | ||
| SIGCONT | Continue | None |
| SIGCHLD | Child | None |
| SIGTTIN | ||
| SIGTTOU | ||
| SIGIO | ||
| SIGVTALRM | ||
| SIGPROF | ||
| SIGWINCH | ||
| SIGINFO |
On AIX, the file
| /usr/include/sys/signal.h | identifies the signals. |
Here's a sample Korn shell program that illustrates use of signals. It also shows some of the limitations for users to override the signal's default behavior.
==========================================================
Work with signals:
- Below is a Korn shell script that allows a user to see how selected signals are handled using the Unix "kill" command.
- Also try interrupting the script using key sequences like <CTRL>-C, <CTRL>-Z and <CTRL>-\
- The script is documented to help explain the operating system concepts associated with signals.
There is a copy of this script attached to simplify setup. However, the script still needs to be executable:
# chmod +x testsignal.ksh
==========================================================
#!/bin/ksh
# The first line ensures this script will be interpreted by the Korn shell program
#
# user functions for handling signal
onsighup ()
{
print "\nReceived SIGHUP signal"
print "Used to tell daemons to reread their config files."
print Trying to override default behavior and exit
exit
}
#
onsigterm ()
{
print "\nReceived SIGTERM signal"
print "Used for normal termination of a process."
print Trying to override default behavior and exit
exit
}
#
onsigquit ()
{
print "\nReceived SIGQUIT signal"
print "Used to force a program to stop."
print Trying to override default behavior and exit
exit
}
#
onsigint ()
{
print "\nReceived SIGINT signal"
print "Used to force a program to stop."
print Trying to override default behavior and exit
exit
}
#
onsigkill ()
{
print "\nReceived SIGKILL signal"
print "Used to force a program to stop."
print Trying to override default behavior and exit
exit
}
onsigsegv ()
{
print "\nReceived SIGSEGV signal"
print "Used to force a program to abort with a core file."
print Trying to override default behavior and exit
exit
}
#
onsigusr1 ()
{
print "\nReceived SIGUSR1 signal"
print "A user defined signal with no standard behavior."
print Trying to override default behavior and exit
exit
}
#
sethandler ()
{
# Find the number for the signal name:
# This command lists the contents of 2 files, then searches
# for a string passed into this function. Finally, it takes
# the 3rd word of the first line and assigns the result to
# the variable "x".
x=$(cat /usr/include/signal.h /usr/include/sys/signal.h | grep $1 | head -1 | awk '{print $3}')
print $1 is signal $x
# lower case the parameter passed in and concatonate with "on"
typeset -l y=on$1
# set a string to be used after returning from this function
# sample trap: trap SIGHUP onsighup
trapstring="$y $x"
}
#
# MAIN PROGRAM STARTS HERE
#
# Uncomment next line to enable debugging
# set -x
#
# It is good to know who you are running as
print Running as user:
id
# and what this process looks like
print This process looks like:
ps -flp $$
#
# Other useful environment information that can be captured:
# What environment variables are set?
# env
# What limits are set for file sizes, number of processes that can run, etc.?
# ulimit -a
# What are the default file permissions?
# umask
#
print Setting up signal handlers...
#
# Setting SIGHUP by calling sethandler function
sethandler SIGHUP
trap $trapstring
#
# Setting SIGINT by calling sethandler function
sethandler SIGINT
trap $trapstring
#
# Setting SIGQUIT by calling sethandler function
sethandler SIGQUIT
trap $trapstring
#
# Setting SIGTRAP by calling sethandler function
sethandler SIGTRAP
trap $trapstring
#
# Setting SIGKILL by calling sethandler function
sethandler SIGKILL
trap $trapstring
#
# Setting SIGSEGV by calling sethandler function
sethandler SIGSEGV
trap $trapstring
#
# Setting SIGUSR1 by calling sethandler function
sethandler SIGUSR1
trap $trapstring
#
# Get summary of trap settings by running trap without parameters
print "\nListing signal handlers set:"
trap
#
# Display process ID and syntax for a kill
print "\nCurrent process is $$"
print From a different shell, send a signal to this process.
print For example: kill -3 $$
#
# Loop until receiving a signal or count reaches 100.
# Will print a dot each 5 seconds.
let i=0
while test $i -lt 100
do
{
print -n "."
sleep 5
let i=$i+1
}
done
#
print "\nExiting, counter has reached $i"
print Check /usr/include/signal.h or usr/include/sys/signal.h
print for complete list of defined signals
#
Was this topic helpful?
Document Information
Modified date:
07 September 2022
UID
swg27003858