7 ms·

All about Linux signals - Linux Programming Blog

61 points by jenhsun 15y ago

ajross 15y ago
Arrgh. How does an article titled "All about Linux signals" not even mention the signalfd() syscall once? Folks: if you're on Linux and need to use signals (i.e. you're reading this article for any practical reason), you need to be using signalfd(). It's not portable to other OSes, but it solves pretty much all the reentrancy and synchronization issues discussed both here and in the article in a very clean way. You get a file descriptor on which you can block cleanly (c.f. select/poll/epoll) and from which you read event notifications on received signals. Seriously, use it. And OP: please update the blog post to at least point people at it. There's no excuse on a modern linux system for trying to use anything else.
- krakensden 15y ago
  It is, you just missed it. FTFA: > First we must block the signals we want to handle with signalfd(2) using sigprocmask(2). This function will be described later. Then we call signalfd(2) to create a file descriptor...
  - ajross 15y ago
    OK, I call uncle. I can't find that text. It's not on the page titled "waiting for a signal", which seems like the obvious candidate. Nor is it in "signals and threads", which would have been my second choice. Nor "That's not everything!". Enlighten me with a link?
    - krakensden 15y ago
      I clicked "show full page", but I think it's on page 3 http://www.linuxprogrammingblog.com/all-about-linux-signals?page=3 http://www.linuxprogrammingblog.com/all-about-linux-signals?...
- halayli 15y ago
  http://www.linuxprogrammingblog.com/all-about-linux-signals?page=3 http://www.linuxprogrammingblog.com/all-about-linux-signals?... http://www.linuxprogrammingblog.com/code-examples/signalfd http://www.linuxprogrammingblog.com/code-examples/signalfd I just wish freebsd and linux folks agree on a standard instead of dealing with multiple ways to handle async events via different poller implementations and hacks.
antirez 15y ago
Signals are one of the most dangerous features of POSIX, but this guide is awesome. I used this resource while writing the Redis 2.6 "Software Watchdog" feature (documented at the end of this page: http://redis.io/topics/latency http://redis.io/topics/latency). Cool that it was posted here just a few days later.
- javert 15y ago
  What exactly makes you say they are dangerous? Genuinely curious. Certain kinds of programmer error? (I haven't finished reading the guide yet... apologies if it's in there... but I'd say I'm pretty familiar with signals.)
  - antirez 15y ago
    reentrancy of everything called inside a signal handler, interrupted system calls to handle, complexity in masking/unmasking, reinstalling of signal handler, and so forth. It's a very complex system.
    - javert 15y ago
      That's what I figured was being referred to. Those things aren't so bad if you really know what you're doing.
  - calloc 15y ago
    There are certain race conditions if you rely on signals to interrupt system calls and the interrupt happens before the syscall is called (after setting the signal, but before the syscall happens). Since your code could have been anywhere in the execution path you can only do very limited amount of things within the signal handler that won't cause catastrophic issues otherwise.
    - javert 15y ago
      certain race conditions if you rely on signals to interrupt system calls and the interrupt happens before the syscall is called I'm pretty familiar with signals, but I don't really know what the problem is here. Why would you rely on signals to interrupt system calls? Maybe if I know why you would do that, I will see why it's a problem if the signal comes before the syscall happens.
sciurus 15y ago
Part 3 of Neil Brown's "Ghosts of Unix past" series has an interesting take on signals. The conclusion is that "signal handlers are perfectly workable for some of the early use cases (e.g. SIGSEGV) it seems that they were pushed beyond their competence very early, thus producing a broken design for which there have been repeated attempts at repair. While it may now be possible to write code that handles signal delivery reliably, it is still very easy to get it wrong. The replacement that we find in signalfd() promises to make event handling significantly easier and so more reliable." https://lwn.net/Articles/414618/ https://lwn.net/Articles/414618/
calloc 15y ago
One thing to please keep in mind (knowing that it is called the linux programming blog ...) is that if you program your app around specific Linux only signals/and or methods (aka signalfd) it might be and most likely will be more difficult to port your code to other platforms such as Solaris/BSD/HP-UX/AIX and the like. Having ported my fair share of code from open source projects that only ran on Linux to FreeBSD I feel like too much emphasis is put on using Linux only stuff making it difficult or extremely hard to port code in a clean manner.
- krakensden 15y ago
  On the other hand, signalfd is kind of wonderful, and it's not like FreeBSD is about to suddenly experience a renaissance.
  - eropple 15y ago
    OS X, however? It's not particularly hard to emulate (most of) signalfd()'s behavior by writing a byte to a pipe and checking for it in your main loop.
    - krakensden 15y ago
      Surely you mean iOS. In which case, I'm not sure why you would be spending much time worrying about signals.
      - eropple 15y ago
        Er, no, thank you, I very much do not mean iOS. I mean OS X, which, irrespective of your (obnoxiously communicated) opinion of it, is rather popular amongst Unix developers and it tends to be a good idea to write your Unix code to support it.
  - X-Istence 15y ago
    Feeding a troll ... may not be my smartest move yet. Yes, signalfd() is wonderful and nice, but it makes it a pain in the behind to port your software. If you need to use signals and do it in an event loop of some sort take a look at libev which abstracts away the OS and handles it in the best way possible depending on the system it is run on. Not only that, but libev will make use of epoll/kqueue/select/poll as required on the OS it is running on, so you get easier portability with the various different event mechanisms that do exist across systems.
deleted 15y ago
[deleted]
thelastnode 15y ago
Took me a second to find, but here's the all-on-one-page version: http://www.linuxprogrammingblog.com/all-about-linux-signals?page=show http://www.linuxprogrammingblog.com/all-about-linux-signals?...
noselasd 15y ago
I'd like some more around the "Interrupting system calls" section. This is a real can of worms. By default, signal() defaults to BSD semantics , which auto restarts syscalls, as do the SA_RESTART flag when the handler is established with sigaction(). Except not all calls are auto restarted, e.g. select/poll/sleep, I'd really like to see a list of syscalls that are not restarted no matter the flags. And the macros that (implicitly) turn on SysV behavior of signal() ...
- antirez 15y ago
  Another thing that's not very clear from the document is: if the signal arrives in the course of a non-interruptible system call, when will it be delivered? As soon as the system call ends or anytime in the (near) future? Probably POSIX does not define this behavior, but it's useful for the programmer to know how most operating systems handle this. Another interesting thing that I had to read in the Linux source code to be sure is that non-fatal signals can't interrupt a write(2) against the filesystem (and you can't have a short write count returned because of a signal). This is an assumption many programs rely on.
- calloc 15y ago
  The Linux man page on signals is surprisingly helpful in that regard: http://linux.die.net/man/7/signal http://linux.die.net/man/7/signal

61 points by jenhsun 15y ago

Arrgh. How does an article titled "All about Linux signals" not even mention the signalfd() syscall once? Folks: if you're on Linux and need to use signals (i.e. you're reading this article for any practical reason), you need to be using signalfd(). It's not portable to other OSes, but it solves pretty much all the reentrancy and synchronization issues discussed both here and in the article in a very clean way. You get a file descriptor on which you can block cleanly (c.f. select/poll/epoll) and from which you read event notifications on received signals. Seriously, use it. And OP: please update the blog post to at least point people at it. There's no excuse on a modern linux system for trying to use anything else.

krakensden 15y ago
It is, you just missed it. FTFA: > First we must block the signals we want to handle with signalfd(2) using sigprocmask(2). This function will be described later. Then we call signalfd(2) to create a file descriptor...
- ajross 15y ago
  OK, I call uncle. I can't find that text. It's not on the page titled "waiting for a signal", which seems like the obvious candidate. Nor is it in "signals and threads", which would have been my second choice. Nor "That's not everything!". Enlighten me with a link?
  - krakensden 15y ago
    I clicked "show full page", but I think it's on page 3 http://www.linuxprogrammingblog.com/all-about-linux-signals?page=3 http://www.linuxprogrammingblog.com/all-about-linux-signals?...
halayli 15y ago
http://www.linuxprogrammingblog.com/all-about-linux-signals?page=3 http://www.linuxprogrammingblog.com/all-about-linux-signals?... http://www.linuxprogrammingblog.com/code-examples/signalfd http://www.linuxprogrammingblog.com/code-examples/signalfd I just wish freebsd and linux folks agree on a standard instead of dealing with multiple ways to handle async events via different poller implementations and hacks.

antirez 15y ago

Signals are one of the most dangerous features of POSIX, but this guide is awesome. I used this resource while writing the Redis 2.6 "Software Watchdog" feature (documented at the end of this page: http://redis.io/topics/latency http://redis.io/topics/latency). Cool that it was posted here just a few days later.

javert 15y ago
What exactly makes you say they are dangerous? Genuinely curious. Certain kinds of programmer error? (I haven't finished reading the guide yet... apologies if it's in there... but I'd say I'm pretty familiar with signals.)
- antirez 15y ago
  reentrancy of everything called inside a signal handler, interrupted system calls to handle, complexity in masking/unmasking, reinstalling of signal handler, and so forth. It's a very complex system.
  - javert 15y ago
    That's what I figured was being referred to. Those things aren't so bad if you really know what you're doing.
- calloc 15y ago
  There are certain race conditions if you rely on signals to interrupt system calls and the interrupt happens before the syscall is called (after setting the signal, but before the syscall happens). Since your code could have been anywhere in the execution path you can only do very limited amount of things within the signal handler that won't cause catastrophic issues otherwise.
  - javert 15y ago
    certain race conditions if you rely on signals to interrupt system calls and the interrupt happens before the syscall is called I'm pretty familiar with signals, but I don't really know what the problem is here. Why would you rely on signals to interrupt system calls? Maybe if I know why you would do that, I will see why it's a problem if the signal comes before the syscall happens.

sciurus 15y ago

Part 3 of Neil Brown's "Ghosts of Unix past" series has an interesting take on signals. The conclusion is that "signal handlers are perfectly workable for some of the early use cases (e.g. SIGSEGV) it seems that they were pushed beyond their competence very early, thus producing a broken design for which there have been repeated attempts at repair. While it may now be possible to write code that handles signal delivery reliably, it is still very easy to get it wrong. The replacement that we find in signalfd() promises to make event handling significantly easier and so more reliable." https://lwn.net/Articles/414618/ https://lwn.net/Articles/414618/

calloc 15y ago

One thing to please keep in mind (knowing that it is called the linux programming blog ...) is that if you program your app around specific Linux only signals/and or methods (aka signalfd) it might be and most likely will be more difficult to port your code to other platforms such as Solaris/BSD/HP-UX/AIX and the like. Having ported my fair share of code from open source projects that only ran on Linux to FreeBSD I feel like too much emphasis is put on using Linux only stuff making it difficult or extremely hard to port code in a clean manner.

krakensden 15y ago
On the other hand, signalfd is kind of wonderful, and it's not like FreeBSD is about to suddenly experience a renaissance.
- eropple 15y ago
  OS X, however? It's not particularly hard to emulate (most of) signalfd()'s behavior by writing a byte to a pipe and checking for it in your main loop.
  - krakensden 15y ago
    Surely you mean iOS. In which case, I'm not sure why you would be spending much time worrying about signals.
    - eropple 15y ago
      Er, no, thank you, I very much do not mean iOS. I mean OS X, which, irrespective of your (obnoxiously communicated) opinion of it, is rather popular amongst Unix developers and it tends to be a good idea to write your Unix code to support it.
- X-Istence 15y ago
  Feeding a troll ... may not be my smartest move yet. Yes, signalfd() is wonderful and nice, but it makes it a pain in the behind to port your software. If you need to use signals and do it in an event loop of some sort take a look at libev which abstracts away the OS and handles it in the best way possible depending on the system it is run on. Not only that, but libev will make use of epoll/kqueue/select/poll as required on the OS it is running on, so you get easier portability with the various different event mechanisms that do exist across systems.

deleted 15y ago

[deleted]

thelastnode 15y ago

Took me a second to find, but here's the all-on-one-page version: http://www.linuxprogrammingblog.com/all-about-linux-signals?page=show http://www.linuxprogrammingblog.com/all-about-linux-signals?...

noselasd 15y ago

I'd like some more around the "Interrupting system calls" section. This is a real can of worms. By default, signal() defaults to BSD semantics , which auto restarts syscalls, as do the SA_RESTART flag when the handler is established with sigaction(). Except not all calls are auto restarted, e.g. select/poll/sleep, I'd really like to see a list of syscalls that are not restarted no matter the flags. And the macros that (implicitly) turn on SysV behavior of signal() ...

antirez 15y ago
Another thing that's not very clear from the document is: if the signal arrives in the course of a non-interruptible system call, when will it be delivered? As soon as the system call ends or anytime in the (near) future? Probably POSIX does not define this behavior, but it's useful for the programmer to know how most operating systems handle this. Another interesting thing that I had to read in the Linux source code to be sure is that non-fatal signals can't interrupt a write(2) against the filesystem (and you can't have a short write count returned because of a signal). This is an assumption many programs rely on.
calloc 15y ago
The Linux man page on signals is surprisingly helpful in that regard: http://linux.die.net/man/7/signal http://linux.die.net/man/7/signal