CMS UNIX Signal Handlers
Complete:
Unix Signal Handler Service
The Unix signal handler service is automatically initialized early in any
cmsRun job. There are no configuration parameters for this service so this
note is primarily "For Your Information" except for one important detail
for developers who may choose to define a new processing thread.
The POSIX standard states that if multiple threads indicate their willingness
to accept delivery of some particular Unix signal, the result is
undefined
behavior: the signal will be delivered to some thread but it cannot
be predicted
a priori which one. As a consequence of this, we have
adopted a policy to require that
- only the main thread - the one that includes the main program - will accept signal delivery, and,
- all other threads must refuse them.
Developers who define additional threads must set the signal
mask to refuse signal delivery immediately after the new thread is created.
There is a small set of free functions in
FWCore/Utilities
to manipulate
signal masks. The interface for these is defined in
FWCore/Utilities/interface/UnixSignalHandlers.h
We note that Root is in the main thread at present and that it has provided
functions to handle 15 of the 31 defined signals (excluding the 32 real-time
signals available on Linux systems). We have added a handler for SIGUSR2
to tell the CMS.EventProcessor to stop processing on completion of the current
event, close open files and shut down cleanly rather than go on to the next
event.
Signal names, numbers and their description
The attached table shows the list of signal names, signal numbers and their
description. Where a handler is defined - either by Root or by the framework
- we list how CMSSW responds. When there is no user defined response, the
system default is taken.
/* Signal number definitions. Linux version.
* Copyright (C) 1995,1996,1997,1998,1999,2003 Free Software Foundation, Inc.
*/
System System Description Root Root Response
Name Value Name Value
SIGHUP 1 Hangup System default
SIGINT 2 Interrupt kSigInterrupt 6 Exit
SIGQUIT 3 Quit kSigQuit 5 Dump and exit
SIGILL 4 Illegal instruction kSigIllegalInstruction 4 Dump and exit
SIGTRAP 5 Trace trap System default
SIGABRT 6 Abort System default
SIGIOT 6 IOT trap System default
SIGBUS 7 BUS error kSigBus 0 Dump and exit
SIGFPE 8 Floating-point exception kSigFloatingException 11 Dump and exit
SIGKILL 9 Kill, unblockable System default
SIGUSR1 10 User-defined signal 1 kSigUser1 13 Exit
SIGSEGV 11 Segmentation violation kSigSegmentationViolation 1 Dump and exit
SIGUSR2 12 User-defined signal 2 kSigUser2 14 Clean exit
SIGPIPE 13 Broken pipe kSigPipe 3 Exit
SIGALRM 14 Alarm clock kSigAlarm 8 Exit
SIGTERM 15 Termination kSigTermination 12 Exit
SIGSTKFLT 16 Stack fault. System default
SIGCLD SIGCHLD Same as SIGCHLD Ignore
SIGCHLD 17 Child status has changed kSigChild 9 Ignore
SIGCONT 18 Continue System default
SIGSTOP 19 Stop, unblockable System default
SIGTSTP 20 Keyboard stop Sytsem default
SIGTTIN 21 Background read from tty System default
SIGTTOU 22 Background write to tty System default
SIGURG 23 Urgent condition on socket kSigUrgent 10 Ignore
SIGXCPU 24 CPU limit exceeded System default
SIGXFSZ 25 File size limit exceeded System default
SIGVTALRM 26 Virtual alarm clock System default
SIGPROF 27 Profiling alarm clock System default
SIGWINCH 28 Window size change kSigWindowChanged 7 Ignore
SIGPOLL SIGIO Pollable event occurred System default
SIGIO 29 I/O now possible System default
SIGPWR 30 Power failure restart System default
SIGSYS 31 Bad system call. kSigSystem 2 Ignore
SIGUNUSED 31
_NSIG 65 Biggest signal number + 1 (including real-time signals).
Notes
- Dumps may or may not be accompanied by a stack trace. When no stack trace was produced, one can always be obtained with gdb provided both the executable and the core.nnnn files are still available. This will probably not be true for farm or grid jobs.
- Exit is equivalent to calling
exit();
and will almost surely leave the last event in a mangled state. Open files are closed but the last "record" will probably be incomplete.
- Clean exit means finish up the current event, write output files and shut down cleanly instead of going on to the next event.
Review Status
Responsible:
ChrisDJones
Last reviewed by: MostRecentReviewer