• Common sources of Linux signals. Source: Brown 2015.
    image
  • Listing Linux signals using the kill command. Source: Choudhary 2018.
    image
  • Describing a few important Linux signals. Source: Walberg and Brunson 2015, table 7-2.
    image
  • Example exchange of signals between parent and child processes. Source: Marek 2012.
    image
  • Signals when handled interrupt program execution. Source: Brown 2015.
    image
  • Signals remain pending until they are unblocked for delivery. Source: Lynx 2019.
    image

Linux Signals

userimg
vpandey
893 DevCoins
userimg
arvindpdmn
5 DevCoins
2 authors have contributed to this article
Last updated by arvindpdmn
on 2019-07-09 16:52:58
Created by vpandey
on 2019-07-08 16:21:35
Improve this article. Show messages

Summary

 image
Common sources of Linux signals. Source: Brown 2015.

A Linux computer system has many processes in different states. These processes belong to either user applications or the operating system. We need a mechanism for the kernel and these processes to coordinate their activities. One way to do this is for a process to inform others when something important happens. This is why we have signals.

A signal is basically a one-way notification. A signal can be sent by the kernel to a process, by a process to another process, or a process to itself.

Linux signals trace their origins to Unix signals. In later Linux versions, real-time signals were added. Signals are a simple and lightweight form of interprocess communication, and therefore suited for embedded systems.

Milestones

1990

Signals are described in the POSIX.1-1990 standard. These can be traced to the IEEE Std 1003.1-1988.

1993

Real-time extensions are released as POSIX.1b. This includes real-time signals.

1999

Linux starts supporting real-time signals with the release of kernel version 2.2.

2001
image

More signals are added in the POSIX.1-2001 standard: SIGBUS, SIGPOLL, SIGPROF, SIGSYS, SIGTRAP, SIGURG, SIGVTALRM, SIGXCPU, SIGXFSZ.

Discussion

  • What are the essential facts about Linux signals?
     image
    Describing a few important Linux signals. Source: Walberg and Brunson 2015, table 7-2.

    There are 31 standard signals, numbered 1-31. Each signal is named as "SIG" followed by a suffix. Starting from version 2.2, the Linux kernel supports 33 different real-time signals. These have numbers 32-64 but programmers should instead use SIGRTMIN+n notation. Standard signals have specific purposes but the use of SIGUSR1 and SIGUSR2 can be defined by applications. Real-time signals are also defined by applications.

    Signal number 0, which POSIX.1 calls null signal, is generally not used but kill function uses this as a special case. No signal is sent but it can be used (rather unreliably) to check if the process still exists.

    Linux implementation of signals is fully POSIX compliant. Newer implementation should prefer to use sigaction rather than the traditional signal interface.

    Just as hardware subsystems can interrupt the processor, signals interrupt process execution. They are therefore seen as software interrupts. While interrupt handlers process hardware interrupts, signal handlers process signals.

    Some signals are mapped to specific key inputs: SIGINT for ctrl+c, SIGSTOP for ctrl+z, SIGQUIT for ctrl+\.

  • How does a signal affect the state of a Linux process?
     image
    Example exchange of signals between parent and child processes. Source: Marek 2012.

    Some signals terminate the receiving process: SIGHUP, SIGINT, SIGTERM, SIGKILL. There are signals that terminate the process along with a core dump to help programmers debug what went wrong: SIGABRT (abort signal), SIGBUS (bus error), SIGILL (illegal instruction), SIGSEGV (invalid memory reference), SIGSYS (bad system call). Other signals stop the process: SIGSTOP, SIGTSTP. SIGCONT is a signal that resumes a stopped process.

    A program could override default behaviour. For example, an interactive program could be written to ignore SIGINT (generated by ctrl+c input). Two notable exceptions are SIGKILL and SIGSTOP signals, which can't be ignored, blocked or overridden this way.

    Let's consider the example of a parent process and its child process. Suppose the child sends SIGSTOP to itself, child process will be stopped. This in turns triggers SIGCHLD to the parent. Parent can then signal the child to continue using SIGCONT. When child comes out of stopped state, another SIGCHLD is sent to parent. If later, the child process exits, the final SIGCHLD is sent to parent.

  • Aren't signals similar to exceptions?

    Some programming languages are capable of exceptions using constructs such as try-throw-catch. Signals are not similar to exceptions. Instead, failed system or library calls return non-zero exit codes. When a process is terminated, it's exit code will be 128 plus signal number. For example, a process killed by SIGKILL will return 137 (128+9).

  • Are Linux signals synchronous or asynchronous?

    When signals are generated, they can be considered as synchronous or asynchronous.

    Synchronous signals occur as a result of instructions that have led to an unrecoverable error such as an illegal address access. These signals are sent to the thread that caused it. These are also called traps, since they also cause a trap into the kernel trap handler.

    Asynchronous signals are external to the current execution context. Sending SIGKILL from an another process is an example of this. These are also called software interrupts.

  • What's the typical lifecycle of a signal?
     image
    Signals when handled interrupt program execution. Source: Brown 2015.

    A signal goes through three stages:

    • Generation: A signal can be generated by the kernel or any of the processes. Whoever generates the signal, addresses it to a specific process. A signal is represented by its number and has no extra data or arguments. Thus, signals are lightweight. However, extra data can be passed along for POSIX real-time signals. System calls and functions that can generate signals include raise, kill, killpg, pthread_kill, tgkill, and sigqueue.
    • Delivery: A signal is said to be pending until it's delivered. Normally a signal is delivered to a process as soon as possible by the kernel. However, if the process has blocked the signal, it will remain pending until unblocked.
    • Processing: Once a signal is delivered, it is processed in one of many ways. Every signal has an associated default action: ignore the signal; or terminate the process, sometimes with a core dump; or stop/continue the process. For non-default behaviour, handler function can be called. Exactly which of these happens is specified via sigaction function.
  • Could you explain the concept of blocking and unblocking signals?
     image
    Signals remain pending until they are unblocked for delivery. Source: Lynx 2019.

    Signals interrupt the normal flow of program execution. This is undesirable when the process is executing some critical code or updating data that's shared with signal handlers. Blocking solves this problem. The tradeoff is that signal handling is delayed.

    Every process can specify if it wants to block a specific signal. If blocked and the signal does occur, the operating system will hold the signal as pending. The signal will be delivered once the process unblocks it. The set of currently blocked signals is called signal mask.

    There's no point blocking a signal indefinitely. For this purpose, the process can instead ignore the signal once it's delivered.

    A signal blocked by one processes doesn't affect other processes, who can receive the signal normally.

    Signal mask can be set using sigprocmask (single-threaded) or pthread_sigmask (multi-threaded). When a process has multiple threads, a signal can be blocked on a per thread basis. Signal will be delivered to any one thread that hasn't blocked it. Essentially,

    Signal handlers are per process, signal masks are per thread.

  • Can we have more than one signal pending for a process?

    Yes, many standard signals can be pending for a process. However, only one instance of a given signal type can be pending. This is because pending and blocking of signals are implemented as bitmasks, with one bit per signal type. For example, we can have SIGALRM and SIGTERM pending at the same time but we can't have two SIGALRM signals pending. The process will receive only one SIGALRM signal even if raised multiple times.

    With real-time signals, signals can be queued along with data, so that each instance of the signal can individually delivered and handled.

    POSIX doesn't specify the order of delivery for standard signals, or what happens if both standard and real-time signals are pending. Linux gives priority to standard signals. For real-time signals, lower numbered signals are delivered first, and if many are queued for a signal type, earliest one is delivered first.

Sample Code

  • // Adapted from source: http://www.firmcodes.com/signals-in-linux/
    // Accessed: 2019-07-09
     
    // Example shows a custom handler for SIGINT
    // but the handler reverts to default action for future signals.
    // Thus, first ctrl+c will allow program to continue
    // and second ctrl+c will terminate the program.
     
    #include <unistd.h>
    #include <stdio.h>
    #include <signal.h>
     
    void sig_handler1(int num)
    {
    	printf("You are here becoz of signal: %d\n", num);
    	signal(SIGINT, SIG_DFL);
    }
     
    int main()
    {
    	signal(SIGINT, sig_handler1);
    	while(1)
    	{
    		printf("Hello\n");
    		sleep(2);
    	}
    }

References

  1. A Cloud Chef. 2018. "Linux Process States and Signals." Medium, August 27. Accessed 2019-07-09.
  2. Bar, Moshe. 2000. "The Linux Signals Handling Model." Linux Journal, May 01. Accessed 2019-07-09.
  3. Brown, Chris. 2015. "Core Technology: Signals." Linux Voice, November 18. Accessed 2019-07-09.
  4. Choudhary, Ajay. 2018. "kill command in Linux with Examples." GeeksforGeeks, December 21. Updated 2019-05-22. Accessed 2019-07-09.
  5. FSF. 2019. "Process Signal Mask." Section 24.7.3 in The GNU C Library, glibc 2.29, Free Software Foundation. Updated 2019-02-01. Accessed 2019-07-09.
  6. Fusco, John. 2007. "The Linux Programmer's Toolbox." Pearson Education. Accessed 2019-07-09.
  7. Haim, Liran Ben. 2017. "Linux – Handling Signals in a Multithreaded Application." Developers Area, November 30. Accessed 2019-07-09.
  8. Hong, K. 2018. "Linux Processes and Signals." BogoToBogo. Accessed 2019-07-09.
  9. Ingargiola, Giorgio. 2009. "Unix Signals." CIS4307 Introduction to Distributed Systems and Networks, College of Science and Technology, Temple University. Accessed 2019-07-09.
  10. Kernel. 1999. "Index of /pub/linux/kernel/v2.2/" Accessed 2019-07-09.
  11. Kerrisk, Michael. 2008. "signal(7) - overview of signals." Linux Programmer's Manual, Linux Foundation. Accessed 2019-07-09.
  12. Lynx. 2019. "POSIX Signals for Embedded and Real-Time Developers." Lynx Software Technologies. Accessed 2019-07-09.
  13. Marek. 2012. "Linux process states." Idea of the day, December 11. Accessed 2019-07-09.
  14. Stevens, W. Richard and Stephen A. Rago. 2013. "Advanced Programming in the UNIX® Environment." Third Edition, Addison-Wesley, Pearson Education, Inc. Accessed 2019-07-09.
  15. Walberg, Sean, and Ross Brunson. 2015. "CompTIA® Linux+ / LPIC-1 Cert Guide: (Exams LX0-103 & LX0-104/101-400 & 102-400)." Pearson IT Certification, December. Accessed 2019-07-09.
  16. Wikipedia. 2019. "POSIX." Wikipedia, June 25. Accessed 2019-07-09.
  17. codingfreak. 2009. "Signals in Linux - Blocking Signals." Blog, codingfreak, April 10. Accessed 2019-07-09.
  18. vasanth2001. 2008. "How to pass input to a signal handler?" LinuxQuestions.org, August 27. Accessed 2019-07-09.

Milestones

1990

Signals are described in the POSIX.1-1990 standard. These can be traced to the IEEE Std 1003.1-1988.

1993

Real-time extensions are released as POSIX.1b. This includes real-time signals.

1999

Linux starts supporting real-time signals with the release of kernel version 2.2.

2001
image

More signals are added in the POSIX.1-2001 standard: SIGBUS, SIGPOLL, SIGPROF, SIGSYS, SIGTRAP, SIGURG, SIGVTALRM, SIGXCPU, SIGXFSZ.

Tags

See Also

  • Interprocess Communication in Linux
  • Linux Process
  • Real-Time Linux
  • Linux
  • UNIX
  • POSIX

Further Reading

  1. Kerrisk, Michael. 2008. "signal(7) - overview of signals." Linux Programmer's Manual, Linux Foundation. Accessed 2019-07-09.
  2. Stevens, W. Richard and Stephen A. Rago. 2013. "Chapter 10: Signals." Advanced Programming in the UNIX® Environment, Third Edition, Addison-Wesley, Pearson Education, Inc. Accessed 2019-07-09.
  3. Brown, Chris. 2015. "Core Technology: Signals." Linux Voice, November 18. Accessed 2019-07-09.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
3
0
893
1
0
5
1264
Words
0
Chats
4
Edits
2
Likes
299
Hits

Cite As

Devopedia. 2019. "Linux Signals." Version 4, July 9. Accessed 2019-08-24. https://devopedia.org/linux-signals