Jump to content

SIGHUP: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Details: not notable
m layout
 
(35 intermediate revisions by 25 users not shown)
Line 1: Line 1:
{{Infobox Computing signal
{{Short description|Unix signal}}
On [[POSIX]]-compliant platforms, '''SIGHUP''' ("'''sig'''nal '''h'''ang '''up'''") is a [[Signal (IPC)|signal]] sent to a [[Process (computing)|process]] when its controlling terminal is closed. It was originally designed to notify the process of a [[RS-232|serial line]] drop. SIGHUP is a [[C preprocessor|symbolic constant]] defined in the [[header file]] <code>[[signal.h]]</code>.
|description = Hangup
|action = Abnormal termination of the process
}}
On [[POSIX]]-compliant platforms, '''SIGHUP''' is a [[Signal (computing)|signal]] sent to a [[process (computing)|process]] when its [[controlling terminal]] is closed. (It was originally designed to notify the process of a [[RS-232|serial line]] drop). SIGHUP is a [[C preprocessor|symbolic constant]] defined in the [[header file]] <code>[[signal.h]]</code>.


==Etymology==
==History==
[[Image:Acoustic coupler 20041015 175456 1.jpg|thumb|A ''hangup'' was often the result of a connected user physically hanging up the modem]]
Access to [[Mainframe computer|computer systems]] for many years consisted of connecting a [[Computer terminal|terminal]] to a mainframe system via a serial line and the [[RS-232]] [[Communications protocol|protocol]]. When a system of software [[interrupt]]s, called signals, was being developed, one of those signals was designated for use on hangup.


SIGHUP would be sent to [[Computer program|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.
''SIG'' is a common [[Prefix (linguistics)|prefix]] for signal names; ''HUP'' is a [[Contraction (grammar)|contraction]] of ''hang up''.


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 [[daemon (computing)|daemons]], would re-purpose SIGHUP as a signal to re-read [[configuration file]]s, or reinitialize. This convention survives to this day in packages such as [[Apache HTTP Server|Apache]] and [[Sendmail]].
==History==
[[Image:Acoustic coupler 20041015 175456 1.jpg|thumb||A ''hangup'' was often the result of a connected user physically hanging up the modem]]
Access to [[Mainframe computer|computer systems]] for many years consisted of connecting a [[Computer terminal|terminal]] to a mainframe system via a serial line and the [[RS-232]] [[Communications protocol|protocol]]. For this reason, when a system of software [[interrupt]]s, called signals, were being developed, a signal was designated for use on "Hangup".

SIGHUP would be sent to [[Computer program|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 [[RS-232#Connectors|DCD]] "carrier detect" signal.


==Modern usage==
==Modern usage==
With the decline of access via serial line, the meaning of SIGHUP has changed somewhat on modern systems, often meaning a controlling [[Terminal emulator|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.<ref name="linux-signal7">{{Citation|chapter-url=https://www.kernel.org/doc/man-pages/online/pages/man7/signal.7.html|chapter=SIGNAL(7)|title=[[Linux Programmer's Manual]] (version 3.22)|editor-last=Kerrisk|editor-first=Michael|date=25 July 2009|publisher=The Linux Kernel Archives|access-date=23 September 2009}}.</ref>


If the process receiving SIGHUP is a [[Unix shell]], then as part of [[Job control (Unix)|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 group]]s, represented internally by the shell as a "job"), which by default terminates them.<ref name="bash-beg">{{Citation|editor-last=Garrels|editor-first=Machtelt|title=Bash Guide for Beginners, ver. 1.11|chapter=Signals|date=27 December 2008|chapter-url=http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_12_01.html|publisher=[[The Linux Documentation Project]]|access-date=23 September 2009}}.</ref>
With the decline of access via serial line, the meaning of SIGHUP has changed somewhat on modern systems, often meaning a controlling [[Terminal emulator|pseudo or virtual terminal]] has been closed (i.e. a command is executed inside a terminal window and the terminal window is closed while the command process is still running).<ref name="linux-signal7">{{Citation|unused_data=2|chapter-url=http://www.kernel.org/doc/man-pages/online/pages/man7/signal.7.html|chapter=SIGNAL(7)|title=[[Linux Programmer's Manual]] (version 3.22)|editor-last=Kerrisk|editor-first=Michael|date=25 July 2009|publisher=The Linux Kernel Archives|accessdate=23 September 2009}}.</ref>


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 (Unix)|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.
If the program receiving SIGHUP is a [[Unix shell]], it will often intercept the signal and ensure all stopped programs are continued before sending the signal to child jobs.<ref name="bash-beg">{{Citation|editor-last=Garrels|editor-first=Machtelt|title=Bash Guide for Beginners, ver. 1.11|chapter=Signals|date=27 December 2008|chapter-url=http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_12_01.html|publisher=[[The Linux Documentation Project]]|accessdate=23 September 2009}}.</ref>


Different shells also have other methods of controlling and managing SIGHUP, such as the [[disown (Unix)|disown]] facility of [[KornShell|ksh]]. Most modern [[Linux distribution]]s documentation specify using <code>[[kill (command)|kill]] -HUP <processID></code> to send the SIGHUP signal.<ref name="linux-kill2">{{Citation|chapter-url=https://www.kernel.org/doc/man-pages/online/pages/man2/kill.2.html|date=25 July 2009|chapter=KILL(2)|title=[[Linux Programmer's Manual]] (version 3.22)|editor-last=Kerrisk|editor-first=Michael|publisher=The Linux Kernel Archives|access-date=23 September 2009}}.</ref>
The [[Single UNIX Specification]] describes a shell utility called [[nohup]], which can be used as a wrapper to start a program and make it immune to SIGHUP.


[[Daemon (computing)|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.
Different shells also have other methods of controlling and managing SIGHUP, such as the disown facility of GNU [[Bash (Unix shell)|bash]].<ref name="bash-beg" /> Most modern [[Linux distribution]]s documentation specify using <tt>[[kill (command)|kill]] -HUP <processID></tt> to send the SIGHUP signal.<ref name="linux-kill2">{{Citation|chapter-url=http://www.kernel.org/doc/man-pages/online/pages/man2/kill.2.html|date=25 July 2009|chapter=KILL(2)|title=[[Linux Programmer's Manual]] (version 3.22)|editor-last=Kerrisk|editor-first=Michael|publisher=The Linux Kernel Archives|accessdate=23 September 2009}}.</ref>


==Details==
[[Daemon (computer software)|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.
Symbolic signal names are used because signal numbers can vary across platforms, but [[Single UNIX Specification|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 [[Signal_(IPC)#Handling_signals|handled]]. That is, [[programmer]]s can define the action they want to occur upon receiving a SIGHUP, such as calling a [[subroutine|function]], ignoring it, or restoring the default action.
==References==

{{reflist}}
The default action on [[POSIX]]-compliant systems is an abnormal termination.


==See also==
==See also==
* [[Unix signal]]

* [[Signal (computing)]]
* [[RS-232]]
* [[RS-232]]
* [[Computer terminal]]


==References==
{{Computing signals}}
{{reflist}}


[[Category:Unix signals]]
[[ru:SIGHUP]]

Latest revision as of 01:28, 19 August 2024

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

[edit]
A hangup was often the result of a connected user physically hanging up the modem

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

[edit]

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

[edit]

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.

See also

[edit]

References

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