4

I researched the kill, pkill and killall commands, and I understood most of their differences. However, I am confused about their signals:

If I run kill -l, I see:

 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

But pkill -l gives:

pkill: invalid option -- 'l'

Usage:
 pkill [options] <pattern>

Options:
 -<sig>, --signal <sig>    signal to send (either number or name)
 -e, --echo                display what is killed
 -c, --count               count of matching processes
 -f, --full                use full process name to match
 -g, --pgroup <PGID,...>   match listed process group IDs
 -G, --group <GID,...>     match real group IDs
 -i, --ignore-case         match case insensitively
 -n, --newest              select most recently started
 -o, --oldest              select least recently started
 -P, --parent <PPID,...>   match only child processes of the given parent
 -s, --session <SID,...>   match session IDs
 -t, --terminal <tty,...>  match by controlling terminal
 -u, --euid <ID,...>       match by effective IDs
 -U, --uid <ID,...>        match by real IDs
 -x, --exact               match exactly with the command name
 -F, --pidfile <file>      read PIDs from file
 -L, --logpidfile          fail if PID file is not locked
 --ns <PID>                match the processes that belong to the same
                           namespace as <pid>
 --nslist <ns,...>         list which namespaces will be considered for
                           the --ns option.
                           Available namespaces: ipc, mnt, net, pid, user, uts

 -h, --help     display this help and exit
 -V, --version  output version information and exit

For more details see pgrep(1).

Even when there is no list of signals, this command supports/uses signals, just see in the previous output that appears

-<sig>, --signal <sig>    signal to send (either number or name)

And finally, killall -l returns:

HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT
CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH POLL PWR SYS

Question

  • Why are the signal lists for kill, killall and pkill not the same?

I assumed pkill and killall should had shown the same output as kill -l - and at first glance, it seems like pkill does not support signals.

Environment:

I have this situation for Ubuntu Server 18:04, 20:04 and Fedora Workstation 36

Improve this question
11
  • Do we talk about Linux? Or UNIX? Commented May 16, 2022 at 17:27
  • 3
    pkill has no -l option, so you're just looking at the standard help message. Commented May 16, 2022 at 17:28
  • 6
    On the contrary, it's common for a command when it is given an argument it does not know to either say "what?" or to act as though it was invoked with --help or its equivelant. Giving possible options for one specific argument in response to an unknown argument would be a very odd design decision in my opinion. Commented May 16, 2022 at 17:45
  • 4
    Well, pkill -l (at least on my Arch) does something completely different. You should always read the man page before trying random options. Commented May 16, 2022 at 17:46
  • 5
    Just to complicate things further: Bash has a built-in kill command, so it does not even run the command /bin/kill which the man page describes: it is instead described in the Bash Reference Manual, and judging by your output, you are running that. It also accepts signal names with or without the SIG prefix. Other shells may also have built-ins, or not (you don't tag which specific shell you are using). Commented May 16, 2022 at 22:31

3 Answers 3

Reset to default
13

Why are the signal lists for kill, killall and pkill not the same?

Most likely, because they were implemented differently, with different frames of mind, at different times, by different persons.

You should note that all of the commands have some form of a --signal argument that can specify any signal the kernel is capable of sending, regardless of which signals the inline help or manual pages may have written into them by hand. As always, consult a command's documentation (generally available in the manual with man command) for details on its usage, invocation, and options. You can also check §7 of the manual for details- see List of Kill Signals for instance.

Improve this answer
8
  • According with your latest paragraph so I must assume the pkill and killall commands handle or can use in peace the same set of signals shown by kill command - am I correct? Commented May 16, 2022 at 17:44
  • 1
    About assumptions, it goes in hand with experimentation - I think that is good for any learning path, of course in controlled environments - For example - Linux through VirtualBox. Commented May 16, 2022 at 17:59
  • 6
    @ManuelJordan Each signal has a name and a number. Under the hood, the system call that a kill command has to make only accepts numbers. All the kill commands have an option to specify the signal as a number, and this is almost certain to be passed through unaltered. They also all have the option to specify by name (and will translate names into numbers), and are likely to assign the same names to the same numbers (especially for the widely used ones defined by the POSIX specification), but it's plausible some commands will differ in their support for uncommon signals. Commented May 17, 2022 at 10:49
  • 1
    @ManuelJordan yes, and indeed if you run man 7 signal in Linux, you'll see that the list of signals supported, and their numbers, can vary between versions of Linux, and between Linux architectures. Names should be the most portable, but only the POSIX ones are likely to be widely supported. Commented May 17, 2022 at 13:32
  • 1
    @ManuelJordan - this comment chain is getting rather long, but in short, MacOS is derived from BSD, so its signals (and indeed its manual pages, and implementations of standardized binaries) differ from Linux to varying degrees of significance. Commented May 17, 2022 at 18:16
9

The programs you mention (kill, killall and pkill) with high probability have different authors. And each author decide how to provide help to the user. You can't expect they will have same command line, same options.

You should get in mind some people (including me) read man pages on the OS they work now to avoid entering wrong command :). Read the man page for killall for Linux, Solaris and AIX and you will be surprised

Improve this answer
3
  • I see - I thought exists an explicit nomenclature acceptation for the signals name - for example killall does not respect it about the signals name. The SIG term part is not included. Commented May 16, 2022 at 18:02
  • @ManuelJordan, no. Linux is not controlled corporative development environment and you can't expect same list of options in programs with different purpose Commented May 16, 2022 at 18:04
  • 1
    I see now, thanks for the quick and polite support Commented May 16, 2022 at 18:05
1

The kill program and killall show the same set of signals:

$ /bin/kill -l
HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT
CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH POLL PWR SYS
$ killall -l
HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT
CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH POLL PWR SYS

kill by itself is the shell built-in. pkill just shows no signal listings.

The kill built-in shows the same signals up to signal 31, with the exception of 29 which shows either SIGIO or SIGPOLL, which are synonyms for each other.

Signals above 31 are real-time signals and then some of them are nicked for threads, but they're "different" and generally less used than the ones below 31.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.