While trying to send SIGQUIT I got this:

$ kill -s QUIT 4341      
kill: unknown signal: SIGQUIT
kill: type kill -l for a list of signals

And I was very surprised to see this:

$ kill -l

So, somehow kill doesn't know all signal names. This is Ubuntu artful (yeah time to upgrade it, but it's another issue)

Obviously I sent SIGQUIT just by using a number 3, but, what could cause kill to forget the signal names?

UPD: this is zsh.

$ type kill     
kill is a shell builtin                
$ echo $ZSH_VERSION $ZSH_PATCHLEVEL                                                             
5.0.2 1.5778                           

I verified that /bin/kill works fine, so must be something zsh-specific..

  • this is probably going to require strace or looking through the source code for kill as it's probably something at the system call level of horkage... – thrig Oct 24 '18 at 20:30
  • 3
    For me it looks like you're in some weird shell and running it's builtin kill command. Check your echo $SHELL ? /bin/kill -l vs kill -l ? – Alexander Oct 24 '18 at 20:33
  • Thanks @Alexander you're right, /bin/kill works fine – Dmitry Frank Oct 25 '18 at 6:11
  • This isn't "wierd" and pretty much all job control shells have built-in kill commands, a requisite for being able to kill jobs. – JdeBP Oct 25 '18 at 7:11
  • 1

Your shell is almost certainly zsh, and you probably have kill defined as an alias or a function (check with type kill).

But I'm still not able to reproduce your case:

zsh$ kill -l 30
zsh$ kill -l 31
zsh$ kill -l 32
zsh$ kill -l -96

32 is the index of "ZERR" in the zsh's signal names table, but, as seen, (at least on my system) it's correctly clamped to the max signal number (31).

Please update your question with the version of your zsh (echo $ZSH_VERSION $ZSH_PATCHLEVEL) and of your OS (uname -a). I guess it was one of those bad patches that fester in distribution ports (quick "fixes" not vetted by the upstream developers).


Try installing the zsh package from the artful repository (version 5.2.5) or recompiling a recent version of zsh from source.

The problem was really caused by a bug in older versions of zsh -- the linemarkers generated by gcc/cpp (the # lnum_of_definition "header.h" 3 4 lines added before the expansions of macros defined in the system headers), were confusing the signames2.awk script used to generate the list of signals and numbers. Notice instead of fixing that script, they simply prevented the generation of linemarkers with the -P option of cpp in recent version of zsh.

See here. Thanks to @Stéphane Chazelas for the hint -- I had looked at those awk scripts, but my lack of flair made me not consider them as culprits, since they weren't changed in ages.

  • Thanks, I updated my question. The $ZSH_VERSION $ZSH_PATCHLEVEL are 5.0.2 1.5778. And yeah, it's definitely zsh-specific problem, thanks. – Dmitry Frank Oct 25 '18 at 6:10
  • The clue here is that 32 is not the index of ZERR. Another clue is that kill -l 30 yielded USR1 when I just typed it. Think about the build-time mechanism that makes both of those the case. – JdeBP Oct 25 '18 at 7:27

This has to be a problem with how your zsh executable was built. The list of signals is determined at compile time from the operating system. The “fake signal” ZERR, which represents exits due to an error rather than due to a signal, is added at the end of the list. In your build, somehow, the list of signals from the OS is empty.

Stéphane Chazelas identified a likely culprit, which is a now-fixed incompatibility of the build scripts with recent versions of the GCC compiler. If you just build a more recent version of zsh, the problem should be resolved. But note that Ubuntu artful comes with zsh 5.2, which is more recent than your version. Even the previous long-time support release of Ubuntu has 5.1.1. So there's no reason to keep your own build unless you need this older version for compatibility testing. If you absolutely need to keep this older version, build it with an older version of GCC.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.