I have never used POLL signal, but it is listed as some signal that has default action to do abnormal termination of the process:


It is marked with "Obsolescent" and as such Strictly Conforming POSIX Applications shall not use it.

I found that if I try to trap such a signal in bash (5.0.17) or dash (0.5.10) I get error:

trap: POLL: bad trap

Does that make the shells not POSIX compliant?

P.S. tested by lksh (mksh package version 58-1 in Ubuntu Linux 20.04) in the same system:

sub() {
    trap 'echo sub SIGPOLL; trap - POLL; exit' POLL
    sleep 3 &
    wait $!
    return 0
sub &
sleep 1
kill -s POLL -- $pid
wait $pid
echo $?
trap 'echo SIGPOLL; trap - POLL; kill -s POLL -- $$' POLL
kill -s POLL -- $$
echo not here


I/O possible
  • Does kill -l list the POLL signal at all in your environment?
    – Kusalananda
    Commented Apr 30, 2021 at 20:52
  • @Kusalananda it depends on the shell I run it in. For dash and bash it does not. For lksh it does.
    – jarno
    Commented Apr 30, 2021 at 21:22
  • Can you trap it in lksh?
    – Kusalananda
    Commented Apr 30, 2021 at 21:36
  • @Kusalananda trap definition gives no error, but I am not able to catch the signal by it. At least with the default trap it will print "I/O possible" in stderr and exit with status 157. If I define trap '' POLL it will ignore the signal.
    – jarno
    Commented May 1, 2021 at 2:43
  • @Kusalananda see the edited question
    – jarno
    Commented May 2, 2021 at 7:33

1 Answer 1


No, both shells are conformant in this regard.

Bash does support SIGPOLL on systems that have it, as does dash:

#if defined (SIGPOLL) /* Pollable event (for streams)  */
signal_names[SIGPOLL] = "SIGPOLL";

If your system doesn't have it, the system might itself be non-conformant, but there's nothing to trap.

There is an argument to make that trap is required to support all of the signals named in the table, and that therefore attempting to trap SIGPOLL should be a noop instead of an error even on a system that was itself non-conformant (though conformance is defined at the system level).

However, SIGPOLL is also listed as part of the XSI Streams feature (XSR), which is optional, so a script that uses functionality from it could only be portable to another system that supported XSI Streams. Such a system would also include the POLL signal, and the shells would therefore pick that up as well.

This is conformant behaviour.

  • Please see my comment to the question.
    – jarno
    Commented Apr 30, 2021 at 21:24
  • That doesn't change anything here. Commented Apr 30, 2021 at 21:31
  • So my system has XSR and SIGPOLL when I use lksh, but not when I use dash?!
    – jarno
    Commented May 2, 2021 at 7:45
  • Well, I didn't comment on lksh. Generally on Linux the SIGPOLL constant is never more than an alias for SIGIO, not a distinct signal, but POSIX conformance is defined at the system level, not individual programs—if you got packages from your vendor and they have elected not to support XSI Streams, there's no issue with a program not supporting a gated feature. That is something to take up with Canonical in this instance, rather than the shells individually (it could be a choice, an oversight, a default, who knows). Both Bash and Dash are set up to be conformant in this respect, vendor willing. Commented May 2, 2021 at 8:03
  • Ubuntu doesn't strive for strict POSIX conformance, though, so they may just not care, which is fine too. I wouldn't be writing new scripts that used trap POLL, but I can definitely see the argument for treating it as a noop to ease migration from systems that do have it. It's just not a conformance requirement unless the system claims XSI streams. Commented May 2, 2021 at 8:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .