What is a signal and why does this matter for WebSphere Application Server

White paper


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.
  • This triggers the javacore for the IBM jdks.
  • It triggers a Full Thread Dump for the Sun and HP jdks
  • If heapdump or hprof is enabled, then it dumps the heap.
SIGSEGV Typically, this is caused by an error in native code. It frequently indicates a bug in the native library that generates it.
  • This triggers a javacore for the IBM jdks.
  • It generates a hs_err_pid*.log file for the Sun and HP jdks
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.
  • Examine the logs for a java.lang.StackOverflowError; fix this problem if it exists.
  • Otherwise, try the following steps:
    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
For more information on signals for AIX, see the kill command in the Commands Reference: Volume 3, i-m.

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
#


testsignal.ksh

Cross reference information
Segment Product Component Platform Version Edition
Application Servers IBM HTTP Server Runtime AIX, HPUX, Linux, Solaris
Application Servers Runtimes for Java Technology Java SDK
Application Servers WebSphere Application Server - Express General AIX, HP-UX, Linux, Solaris, Windows 7.0, 6.1, 6.0.2, 6.0.1, 6.0, 5.1.1

Rate this page:

(0 users)Average rating

Document information


More support for:

WebSphere Application Server
General

Software version:

5.1, 6.0, 6.1, 7.0, 8.0, 8.5

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows

Software edition:

Advanced, Base, Express, Network Deployment, Single Server

Reference #:

7003858

Modified date:

2013-03-18

Translate my page

Machine Translation

Content navigation