Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP-UX Reference > S


HP-UX 11i Version 3: February 2007

Technical documentation

» Feedback
Content starts here

 » Table of Contents

 » Index


signal: signal.h — description of signals


#include <signal.h>


The <signal.h> header defines the following symbolic constants, each of which expands to a distinct constant expression of the type:

void (*)(int)

whose value matches no declarable function.


Request for default signal handling.


Return value from signal() in case of error.


Request that signal be held.


Request that signal be ignored.

The following data types are defined through typedef:


Integral type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts


Integral or structure type of an object used to represent sets of signals.


As described in <sys/types.h>.

This header also declares the constants that are used to refer to the signals that occur in the system. Signals defined here begin with the letters SIG. Each of the signals have distinct positive integral values. The value 0 is reserved for use as the null signal (see kill(2)). Additional implementation-dependent signals may occur in the system.

HP-UX supports multiple signal interfaces (see sigaction(2), signal(2), and sigset(3C)) that allow a process to specify the action taken upon receipt of a signal.

The following signals are supported on all implementations. The default actions A (Abort), C (Continue), I (Ignore), S (Stop) and T (Abnormal Termination) are explained after the table.

SIGABRTAProcess abort signal.
 Same as SIGIOT.
SIGALRMTAlarm clock.
SIGBUSAAccess to undefined portion of a memory object.
SIGCHLDIChild process terminated or stopped.
 Same as SIGCLD.
SIGCLDISame as SIGCHLD (also see WARNINGS below).
SIGCONTCContinue executing, if stopped.
SIGEMTASoftware generated signal.
SIGFPEAErroneous arithmetic operation.
SIGILLAIllegal instruction.
SIGIOIAsynchronous I/O signal; see select(2).
 Same as SIGPOLL.
SIGIOTAProcess abort signal. Same as SIGABRT.
SIGINTTTerminal interrupt signal.
SIGKILLTKill (cannot be caught or ignored).
SIGLOSTAFile lock lost (NFS file locking).
SIGPIPETWrite on a pipe with no one to read it.
SIGPOLLTPollable event.
SIGQUITATerminal quit signal.
SIGSEGVAInvalid memory reference.
SIGSTOPSStop executing (cannot be caught or ignored).
SIGTERMTTermination signal.
SIGTSTPSTerminal stop signal.
SIGTTINSBackground process attempting read.
SIGTTOUSBackground process attempting write.
SIGUSR1TUser-defined signal 1.
SIGUSR2TUser-defined signal 2.
SIGPOLLTPollable event.
SIGPROFTProfiling timer expired.
SIGPWRIPower fail (see WARNINGS below).
SIGSYSABad system call.
SIGTRAPATrace/breakpoint trap.
SIGURGIHigh bandwidth data is available at a socket.
SIGVTALRMTVirtual timer expired.
SIGWINCHIWindow size change; see termio(7).
SIGXCPUACPU time limit exceeded.
SIGXFSZAFile size limit exceeded.
SIGRTMINTFirst realtime signal.
SIGRTMAXTLast realtime signal.

The macros SIGRTMIN and SIGRTMAX evaluate to integral expressions, and specify a range that includes at least {RTSIG_MAX} signal numbers that are reserved for application use and for which the realtime signal extensions are supported (see sigaction(2)).

The default actions are as follows:


Abnormal termination of the process. Additionally, for some signals having this default action, If the following conditions are met, generate a core image file (see core(4)) in the current working directory of the receiving process:

  • The effective user ID and the real user ID of the receiving process are equal.

  • The effective group ID and the real group ID of the receiving process are equal.

  • A regular file named core does not exist and can be created, or exists and is writable.

If the file is created, it has the following properties:

  • The file mode is 0600, modified by the file creation mode mask (see umask(2)).

  • The file user ID is equal to the effective user ID of the receiving process.

  • The file group ID is equal to the effective group ID of the receiving process.


Continue the process, if it is stopped; otherwise ignore the signal.


Ignore the signal.


Stop the process. While a process is stopped, any additional signals sent to the process are suspended until the process is restarted (except SIGKILL, which is processed immediately). However, when the process is restarted, pending signals are processed. When a process that is in an orphaned process group (see glossary(9)) receives a SIGTSTP, SIGTTIN, or SIGTTOU signal, the process is not stopped because a process in an orphaned process group is not allowed to stop. Instead, a SIGHUP signal is sent to the process, and the SIGTSTP, SIGTTIN, or SIGTTOU is discarded.


Abnormal termination of the process. The process is terminated with all the consequences of exit() except that the status made available to wait() and waitpid() indicates abnormal termination by the specified signal. See exit(2), wait(2), waitpid(2).

The header provides a declaration of struct sigaction, including at least the following members:

void(*sa_handler)(int)what to do on receipt of signal
sigset_tsa_maskset of signals to be blocked during execution of the signal handling function
intsa_flagsspecial flags
void (*)sa_sigactionpointer to signal
(int, siginfo_t *, void *)handler function
or one of the macros

The storage occupied by sa_handler and sa_sigaction may overlap, and a portable program must not use both simultaneously.

The following are declared as constants:


Do not generate SIGCHLD when children stop.


The resulting set is the union of the current set and the signal set pointed to by the argument set.


The resulting set is the intersection of the current set and the complement of the signal set pointed to by the argument set.


The resulting set is the signal set pointed to by the argument set. SA_ONSTACK Causes signal delivery to occur on an alternate stack.


Causes signal dispositions to be set to SIG_DFL on entry to signal handlers.


Causes certain functions to become restartable.


Causes extra information to be passed to signal handlers at the time of receipt of a signal.


Causes implementations not to create zombie processes on child death.


Causes signal not to be automatically blocked on entry to signal handler.


Process is executing on an alternate signal stack.


Alternate signal stack is disabled.


Minimum stack size for a signal handler.


Default size in bytes for the alternate signal stack.

The ucontext_t structure is defined through typedef as described in <ucontext.h>.

The mcontext_t structure is defined through typedef as described in <ucontext.h>.

The <signal.h> header defines the stack_t type as a structure that includes at least the following members:

void*ss_spstack base or pointer
size_tss_sizestack size

The <signal.h> header defines the sigstack structure that includes at least the following members:

intss_onstacknonzero when signal stack is in use
void*ss_spsignal stack pointer

The <signal.h> header defines the sigevent structure that includes at least the following members:

intsigev_notifyNotification type
intsigev_signoSignal number
union sigvalsigev_valueSignal value.

The sigev_notify member specifies the notification mechanism to use when an asynchronous event occurs. The following values are defined for the sigev_notify member:


No asynchronous notification will be delivered when the event of interest occurs.


The signal specified in sigev_signo will be generated for the process when the event of interest occurs. If SA_SIGINFO is set for that signal number, then the signal will be queued to the process, and the value specified in sigev_value will be the sigev_value component of the generated signal. If SA_SIGINFO is not set for that signal number, it is unspecified whether the signal is queued, and what value, if any, is sent.

The sigev_signo member specifies the signal to be generated. The sigev_value member is the application-defined value to be passed to the signal-catching function at the time of the signal delivery or to be returned at signal acceptance as the si_value member of the siginfo_t structure.

The <signal.h> header defines sigval as a union that includes at least the following members:

intsival_intInteger signal value
void *sival_ptrPointer signal value.

The <signal.h> header defines the siginfo_t type as a structure that includes at least the following members:

intsi_signosignal number
intsi_errnoif nonzero, an errno value associated with this signal, as defined in <errno.h>
intsi_codesignal code
union sigvalsi_valuesignal value
id_tsi_pidsending process ID
uid_tsi_uidreal user ID of sending process
void*si_addraddress of faulting instruction
intsi_statusexit value or signal
longsi_bandband event for SIGPOLL

The si_code member contains a code identifying the cause of the signal. The following values are defined for si_code:


The signal was sent by kill(). The si_code may be set to SI_USER also if the signal was sent by raise() (see kill(2)) or similar functions that are provided as implementation extensions of kill().


The signal was sent by sigqueue().


The signal was generated by the expiration of a timer set by timer_settime().


The signal was generated by the completion of an asynchronous I/O request.


The signal was generated by the arrival of a message on an empty message queue.

If the signal was not generated by one of the functions or events listed above (such as kill(), raise(), sigqueue(), and other functions), the si_code will be set to an implementation-defined value (see the Code column below) that is not equal to any of the values defined above for si_code.

If si_code is one of SI_QUEUE, SI_TIMER, SI_ASYNCIO, or SI_MESGQ, then si_value will contain the application-specified signal value. Otherwise, the contents of si_value are undefined.

The macros specified in the Code column of the following table are defined for use as values of si_code that are signal-specific reasons why the signal was generated.

SIGILLILL_ILLOPCillegal opcode
ILL_ILLOPNillegal operand
ILL_ILLADRillegal addressing mode
ILL_ILLTRPillegal trap
ILL_PRVOPCprivileged opcode
ILL_PRVREGprivileged register
ILL_COPROCcoprocessor error
ILL_BADSTKinternal stack error
SIGFPEFPE_INTDIVinteger divide by zero
FPE_INTOVFinteger overflow
FPE_FLTDIVfloating point divide by zero
FPE_FLTOVFfloating point overflow
FPE_FLTUNDfloating point underflow
FPE_FLTRESfloating point inexact result
FPE_FLTINVinvalid floating point operation
FPE_FLTSUBsubscript out of range
SIGSEGVSEGV_MAPERRaddress not mapped to object
SEGV_ACCERRinvalid permissions for mapped object
SIGBUSBUS_ADRALNinvalid address alignment
BUS_ADRERRnonexistent physical address
BUS_OBJERRobject specific hardware error
SIGTRAPTRAP_BRKPTprocess breakpoint
TRAP_TRACEprocess trace trap
SIGCHLDCLD_EXITEDchild has exited
CLD_KILLEDchild has terminated abnormally and
did not create a core file
CLD_DUMPEDchild has terminated and created a core file
CLD_KILLEDchild was killed
CLD_DUMPEDchild has terminated abnormally
CLD_TRAPPEDtraced child has trapped
CLD_STOPPEDchild has stopped
CLD_CONTINUEDstopped child has continued
SIGPOLLPOLL_INdata input available
POLL_OUToutput buffers available
POLL_MSGinput message available
POLL_PRIhigh priority input available
POLL_HUPdevice disconnected

Implementations may support additional si_code values not included in this list, may generate values included in this list under circumstances other than those described in this list, and may contain extensions or limitations that prevent some values from being generated. Implementations will not generate a different value from the ones described in this list for circumstances described in this list.

In addition, the following signal-specific information will be available:

SIGILLvoid * si_addraddress of faulting instruction
SIGSEGVvoid * si_addraddress of faulting memory reference
SIGCHLDpid_t si_pidchild process ID
int si_statusexit value or signal
uid_t si_uidreal user ID of the process that sent the signal
SIGPOLLlong si_bandband event for POLL_IN, POLL_OUT, or POLL_MSG

For some implementations, the value of si_addr may be inaccurate.

The following are declared as functions and may also be defined as macros:

void (*bsd_signal(int sig, void (*func)(int)))(int); int kill(pid_t pid, int sig); int killpg(pid_t pgrp, int sig); int raise(int sig); int sigaction(int sig, const struct sigaction *act, struct sigaction *oact); int sigaddset(sigset_t *set, int signo); int sigaltstack(const stack_t *ss, stack_t *oss); int sigdelset(sigset_t *set, int signo); int sigemptyset(sigset_t *set); int sigfillset(sigset_t *set); int sighold(int sig); int sigignore(int sig); int siginterrupt(int sig, int flag); int sigismember(const sigset_t *set, int signo); int sigmask(int signum); void (*signal(int sig, void (*func)(int)))(int); int sigpause(int sig); int sigpending(sigset_t *set); int sigprocmask(int how, const sigset_t *set, sigset_t *oset); int sigqueue(pid_t pid, int sig, const union sigval value); int sigrelse(int sig); void *sigset(int sig, void (*disp)(int)))(int); int sigstack(struct sigstack *ss, struct sigstack *oss); int sigsuspend(const sigset_t *sigmask); int sigtimedwait(const sigset_t *set, siginfo_t * info, const struct timespec *timeout); int sigwait(const sigset_t *set, int *sig); int sigwaitinfo(const sigset_t *set, siginfo_t * info);


Upon receipt of the signal, if signal() is used to set the action to the address of a signal handler, the action for the signal caught is reset to SIG_DFL (except SKGILL, SIGTRAP, and SIGPWR). Then, the signal-catching function is executed. Signal interface routines other than signal() normally do not reset the action for the signal caught. However, sigaction() provides a way of specifying this behavior.

The parameters passed to the signal-catching function where signal() is used are:

intsigThe signal number.
intcodeA word of information usually provided
by the hardware.
struct sigcontext*scpA pointer to the machine-dependent
structure sigcontext defined in

The parameters passed to the signal-catching function where sigaction() is used and SA_SIGINFO is not specified are:

intsigThe signal number.

The parameters passed to the signal-catching function where sigaction() is used and SA_SIGINFO is specified are:

intsigThe signal number.
siginfo_t*siginfopInformation on why the signal was
void *contextpCan be cast to a pointer to a ucontext_t
to refer to the thread's context at the
time of the interruption.

Depending on the value of sig, code can be zero and/or scp can be NULL. The meanings of code and scp and the conditions determining when they are other than zero or NULL are implementation-dependent. It is possible for code to always be zero, and scp to always be NULL.

The pointer scp, siginfop, and contextp are valid only during the context of the signal-catching function.

Optional parameters can be omitted from the signal-catching function parameter list, in which case the signal-catching function is exactly compatible with UNIX System V. Truly portable software should not use the optional parameters in signal-catching routines.

Upon return from the signal-catching function, the receiving process resumes execution at the point where it was interrupted.

When a signal is caught during the execution of system calls such as read(), write(), open(), or ioctl() on a slow device (such as a terminal, but not a file on a local filesystem), during a pause() system call or a wait() system call that does not return immediately because a previously stopped or zombie process already exists, the signal-catching function is executed and the interrupted system call returns a -1 to the calling process with errno set to EINTR.

When any stop signal (SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) is generated for a process, pending SIGCONT signals for that process are discarded. Conversely, when SIGCONT is generated for a process, all pending stop signals for that process are discarded. When SIGCONT is generated for a stopped process, the process is continued, even if the SIGCONT signal is blocked or ignored. If SIGCONT is blocked and not ignored, the signal remains pending until it is either unblocked or a stop signal is generated.

Note: When any stop signal (SIGSTOP, SIGTSTP, SIGTIN, SIGTTOU) is posted to threads created with process contention scope, using pthread_kill(), pending SIGCONT signals may not be discarded. Similarly, when SIGCONT is posted to threads created with process contention scope, using pthread_kill(), pending stop signals may not be discarded. However, stop and continue signals posted to threads created with system contention scope, using pthread_kill(), will continue to adhere to the semantics described in the preceding paragraph.

SIGKILL is sent by the system if an exec() system call is unsuccessful and the original program has already been deleted.

Threads Considerations

The following summarizes the signal model for threads:

  • A signal mask which specifies the signals blocked from delivery is associated with each thread.

  • The signal disposition, catch/ignore/default, is a process attribute and is shared by all threads in the process.

  • If the signal action for a signal specifies termination, stop or continue, all threads within the process are terminated, stopped or continued, respectively. This is the case regardless of whether the signal was directed at the process or a specific thread within the process.

  • Signals which are generated by some action associated with a particular thread, such as an invalid pointer dereference, will be delivered to the thread which caused the generation of the signal. These signals are referred to as synchronously generated signals.

  • Signals that are posted to the process by kill() or some asynchronous event such as terminal activity will be delivered to exactly one thread in the process which does not block delivery of the signal; if there is more than one eligible thread, which thread the signal is delivered to may not be able to be determined by an application. If all threads in the process block the signal, then the signal remains pending on the process until a thread unblocks the signal, issues a sigwait() call for the signal or sets the signal disposition to ignore the signal. These signals are referred to as asynchronously generated signals.

  • A thread can post a signal to a particular thread in the same process using pthread_kill(). If the thread which the signal is posted to blocks delivery of the signal, the signal remains pending on the thread.

  • The sigpending() function returns a union of the set of signals pending on the process and on the calling thread.

  • Each PTHREAD_SCOPE_SYSTEM thread may define an alternate signal handling stack. Use of alternate signal stacks in PTHREAD_SCOPE_PROCESS threads will result in indeterminate behavior.

Threadsafe Considerations

Refer to thread_safety(5) for a list of libc and libpthread interfaces which are not thread-safe, cancellation points, cancel safe, async signal safe, and async cancel safe.


The signals SIGCLD and SIGPWR behave differently than those described above in the list of signals in DESCRIPTION.

The actions for these signals is modified as follows:


Setting the action for SIGCLD to SIG_IGN in a parent process prevents exiting children of the calling process from creating a zombie process. If the parent process executes the wait() function, the calling process blocks until all of the child processes of the calling processes terminate. The wait() function then returns a value of -1 with errno set to ECHILD (see wait(2)).

If one of the signal interface routines is used to set the action for SIGCLD to be caught (that is, a function address is supplied) in a process that currently has terminated (zombie) children, a SIGCLD signal is delivered to the parent process immediately.

Signal-catching functions set by signal() are reset when the signal is caught. These functions generally reinstall themselves. If the function associated with SIGCLD reinstalls itself before it has called one of the child wait functions (such as wait(), wait3(), or waitpid()), another SIGCLD signal will be delivered and the handler immediately invoked again (unless the signal is masked). Thus, a signal-catching function for SIGCLD should reinstall itself only after it has called one of the child wait functions. (This similarly applies to signal-catching functions set with sigaction() where SA_RESETHAND or SV_RESETHAND has been specified.)


The SIGPWR signal is sent to all processes after a power interruption when power is restored and the system has done all necessary reinitialization. Processes restart by catching (or ignoring) SIGPWR.

Applications that wish to recover from power failures should catch SIGPWR and take whatever necessary steps to reinitialize itself.

Some implementations do not generate SIGPWR. Only systems with nonvolatile memory can recover from power failures.

The hardware program counter is not advanced when a trap occurs. If the signal generated by a hardware trap is received by a signal-catching function in the user program, the instruction that caused the trap is re-executed upon return from the signal-catching function, causing the trap again, unless program flow is altered by the signal-catching function. For example, the longjmp() routine (see setjmp(3C)) can be called. Using longjmp() ensures software portability across different hardware architectures.

If the signal generated by a hardware trap is not received by a signal-catching function, that is, if the signal is masked or ignored, there may be one of two results:


The instruction causing the trap is executed again, resulting in an infinite program loop


The system detects the situation and causes the program to terminate.


signal was developed by HP, AT&T, and the University of California, Berkeley.


<signal.h>: AES, SVID2, SVID3, XPG2, XPG3, XPG4, FIPS 151-2, POSIX.1, ANSI C

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 1983-2007 Hewlett-Packard Development Company, L.P.