I am developing an application and I would like it to print some runtime stats to the console on demand. kill and signals came to my mind immediately.

Reading through Unix signals on Wiki, SIGINFO seems like the way to go because:

  • It is intended for these purposes
  • Does not terminate the process if the signal handler is not implemented (contrary to SIGUSRx - see here)

However, by inspecting the output of kill -l, it seems my server does not have this signal implemented.

My questions are:

  1. Why is SIGINFO missing on my system? Is it absent on all GNU Linux systems?
  2. Is there an easy (i.e. no kernel/glibc recompilation) way to enable this signal? If none, what would be the hard way?
  3. What alternative signal could I use for my purposes that would not cause any side-effects if not handled by the target process? (I already assume none since I could not find any other suitable signal on the glibc's manual)

Linux metainfo:

Linux whatever 3.18.2-2-ARCH #1 SMP PREEMPT Fri Jan 9 07:37:51 CET 2015 x86_64 GNU/Linux

Update: I am still looking for more information as to why this signal is conditionally excluded from other systems than BSD (see comments below). The signal seems to be quite useful for many purposes so it is hard for me to believe it is just a matter of whim - so what's the real showstopper for this signal to be available on Linux?

  • 2
    Does ^T appear in the output of stty -a? Jan 16, 2015 at 18:42
  • Ah, it does not - I must have mistaken the described behaviour of dd with that on my Mac. ^T during dd execution does nothing on the Linux machine - I will update the question accordingly. Jan 16, 2015 at 19:44
  • Yeah, Ctrl-T and SIGINFO are BSD (and MacOSX) features. Jan 16, 2015 at 20:17
  • But the signal is defined in the GNU C Library which Linux systems use... Is it then disabled on purpose? Jan 16, 2015 at 20:21
  • 2
    @RobertRossmann, the signals are delivered by the kernel. The question is why doesn't the Linux kernel implement it (because they copied SysV signals, probably).
    – Ángel
    Sep 4, 2015 at 22:32

3 Answers 3


There was talk (back in the linux 0.x-1.x days) of adding this (because it was useful on BSD systems) but if I recall correctly there were reasons it was harder to do right on Linux than BSD at the time.

Note that what you're asking about is only a small part of the feature (namely, you're talking about an stty info entry for control-T causing the kernel to deliver SIGINFO to the tty's process group) - that part is "easy" - but having the kernel report information about the process status when it doesn't handle the signal (because at the time very few things had any support for that, the feature was mainly about "is this process spinning or hung" and "what process is it anyway") is harder - ISTR there even being security/trust issues about displaying that information accurately, and whether it should be associated with the Secure Attention Key path. That said, there might be some value in the "easy" version that only sends the signal...

(From personal memory; a quick web search doesn't turn up anything obvious but I think one would have to dig into really old archives to find the discussion.)


Regarding your question 1):

From man 7 signal on an Arch Linux system:

SIGINFO 29,-,- A synonym for SIGPWR

(Signal 29 is SIGINFO / SIGPWR on an alpha but SIGLOST on a sparc.)

SIGPWR (which is not specified in POSIX.1-2001) is typically ignored by default on those other UNIX systems where it appears.

By this definition, SIGINFO only is available on alpha or sparc architectures.


It's because Linux isn't Unix, which in this case means it's inferior. Also the older DEC-systems had control-t. It was very useful, as far as I remember. That was before Unix even; look up e.g. the "TOPS-10 Operating System Commands Manual". Yes, control-t sends SIGINFO on Unix systems, which obviously inherited it.

You must log in to answer this question.

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