SIGHUP

Last updated January 07, 2023

On POSIX-compliant platforms, SIGHUP ("signal hang up") is a signal sent to a process when its controlling terminal is closed. It was originally designed to notify the process of a serial line drop. SIGHUP is a symbolic constant defined in the header file signal.h .

History

Access to computer systems for many years consisted of connecting a terminal to a mainframe system via a serial line and the RS-232 protocol. When a system of software interrupts, called signals, was being developed, one of those signals was designated for use on hangup.

SIGHUP would be sent to programs when the serial line was dropped, often because the connected user terminated the connection by hanging up the modem. The system would detect the line was dropped via the lost Data Carrier Detect (DCD) signal.

Signals have always been a convenient method of inter-process communication (IPC), but in early implementations there were no user-definable signals (such as the later additions of SIGUSR1 and SIGUSR2) that programs could intercept and interpret for their own purposes. For this reason, applications that did not require a controlling terminal, such as daemons, would re-purpose SIGHUP as a signal to re-read configuration files, or reinitialize. This convention survives to this day in packages such as Apache and Sendmail.

Modern usage

With the decline of access via serial line, the meaning of SIGHUP has changed somewhat on modern systems, often meaning a controlling pseudo or virtual terminal has been closed. If a command is executed inside a terminal window and the terminal window is closed while the command process is still running, it receives SIGHUP.^[1]

If the process receiving SIGHUP is a Unix shell, then as part of job control it will often intercept the signal and ensure that all stopped processes are continued before sending the signal to child processes (more precisely, process groups, represented internally by the shell as a "job"), which by default terminates them.^[2]

This can be circumvented in two ways. Firstly, the Single UNIX Specification describes a shell utility called nohup, which can be used as a wrapper to start a program and make it ignore SIGHUP by default. Secondly, child process groups can be "disowned" by invoking disown with the job id, which removes the process group from the shell's job table (so they will not be sent SIGHUP), or (optionally) keeps them in the job table but prevents them from receiving SIGHUP on shell termination.

Different shells also have other methods of controlling and managing SIGHUP, such as the disown facility of ksh. Most modern Linux distributions documentation specify using kill -HUP <processID> to send the SIGHUP signal.^[3]

Daemon programs sometimes use SIGHUP as a signal to restart themselves, the most common reason for this being to re-read a configuration file that has been changed.

Details

Symbolic signal names are used because signal numbers can vary across platforms, but XSI-conformant systems allow the use of the numeric constant 1 to be used to indicate a SIGHUP, which the vast majority of systems in fact use.

SIGHUP can be handled. That is, programmers can define the action they want to occur upon receiving a SIGHUP, such as calling a function, ignoring it, or restoring the default action.

The default action on POSIX-compliant systems is an abnormal termination.

Related Research Articles

Cygwin is a POSIX-compatible programming and runtime environment that runs natively on Microsoft Windows. Under Cygwin, source code designed for Unix-like operating systems may be compiled with minimal modification and executed.

An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs.

The Portable Operating System Interface (POSIX) is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems. POSIX defines both the system- and user-level application programming interfaces (APIs), along with command line shells and utility interfaces, for software compatibility (portability) with variants of Unix and other operating systems. POSIX is also a trademark of the IEEE. POSIX is intended to be used by both application and system developers.

A shell script is a computer program designed to be run by a Unix shell, a command-line interpreter. The various dialects of shell scripts are considered to be scripting languages. Typical operations performed by shell scripts include file manipulation, program execution, and printing text. A script which sets up the environment, runs the program, and does any necessary cleanup or logging, is called a wrapper.

A Unix shell is a command-line interpreter or shell that provides a command line user interface for Unix-like operating systems. The shell is both an interactive command language and a scripting language, and is used by the operating system to control the execution of the system using shell scripts.

The Bourne shell (sh) is a shell command-line interpreter for computer operating systems.

A background process is a computer process that runs behind the scenes and without user intervention. Typical tasks for these processes include logging, system monitoring, scheduling, and user notification. The background process usually is a child process created by a control process for processing a computing task. After creation, the child process will run on its own, performing the task independent of the control process, freeing the control process of performing that task.

A child process in computing is a process created by another process. This technique pertains to multitasking operating systems, and is sometimes called a subprocess or traditionally a subtask.

In computing, a parent process is a process that has created one or more child processes.

<span class="mw-page-title-main">Pseudoterminal</span>

In some operating systems, including Unix and Linux, a pseudoterminal, pseudotty, or PTY is a pair of pseudo-device endpoints (files) which establish asynchronous, bidirectional communication (IPC) channel between two or more processes. The master provides means by which a terminal emulator process controls the slave. The slave, emulates a hardware text terminal device. PTY are similar to bidirectional pipes.

An orphan process is a computer process whose parent process has finished or terminated, though it remains running itself.

Signals are standardized messages sent to a running program to trigger specific behavior, such as quitting or error handling. They are a limited form of inter-process communication (IPC), typically used in Unix, Unix-like, and other POSIX-compliant operating systems.

In computing, kill is a command that is used in several popular operating systems to send signals to running processes.

nohup is a POSIX command which means "no hang up". Its purpose is to execute a command such that it ignores the HUP (hangup) signal and therefore does not stop when the user logs out.

Unix-like operating systems identify a user by a value called a user identifier, often abbreviated to user ID or UID. The UID, along with the group identifier (GID) and other access control criteria, is used to determine which system resources a user can access. The password file maps textual user names to UIDs. UIDs are stored in the inodes of the Unix file system, running processes, tar archives, and the now-obsolete Network Information Service. In POSIX-compliant environments, the command-line command id gives the current user's UID, as well as more information such as the user name, primary user group and group identifier (GID).

In Unix-based computer operating systems, init is the first process started during booting of the computer system. Init is a daemon process that continues running until the system is shut down. It is the direct or indirect ancestor of all other processes and automatically adopts all orphaned processes. Init is started by the kernel during the booting process; a kernel panic will occur if the kernel is unable to start it. Init is typically assigned process identifier 1.

In Unix and Unix-like operating systems, job control refers to control of jobs by a shell, especially interactively, where a "job" is a shell's representation for a process group. Basic job control features are the suspending, resuming, or terminating of all processes in the job/process group; more advanced features can be performed by sending signals to the job. Job control is of particular interest in Unix due to its multiprocessing, and should be distinguished from job control generally, which is frequently applied to sequential execution.

<span class="mw-page-title-main">Fiwix</span> Operating system

Fiwix is an operating system kernel based on the UNIX architecture and fully focused on being POSIX compatible. It is designed and developed mainly as a hobbyist operating system, but it also serves for educational purposes. It runs on the i386 hardware platform and is compatible with a good base of existing GNU applications. It follows the System V Application Binary Interface and is also Linux 2.0 System Call ABI mostly compatible

The POSIX terminal interface is the generalized abstraction, comprising both an application programming interface for programs, and a set of behavioural expectations for users of a terminal, as defined by the POSIX standard and the Single Unix Specification. It is a historical development from the terminal interfaces of BSD version 4 and Seventh Edition Unix.

The Seventh Edition Unix terminal interface is the generalized abstraction, comprising both an application programming interface for programs and a set of behavioural expectations for users, of a terminal as historically available in Seventh Edition Unix. It has been largely superseded by the POSIX terminal interface.

References

↑ Kerrisk, Michael, ed. (25 July 2009), "SIGNAL(7)", Linux Programmer's Manual (version 3.22), The Linux Kernel Archives, retrieved 23 September 2009.
↑ Garrels, Machtelt, ed. (27 December 2008), "Signals", Bash Guide for Beginners, ver. 1.11, The Linux Documentation Project , retrieved 23 September 2009.
↑ Kerrisk, Michael, ed. (25 July 2009), "KILL(2)", Linux Programmer's Manual (version 3.22), The Linux Kernel Archives, retrieved 23 September 2009.