Some processes can't be killed before other processes, so I can think of a case in which kill <PID list> tries to kill such a process, gives up, then kills its "partner" successfully leaving the former unkilled even though it could have killed it too, had it retried later.

If this case is true, another question would be, does kill <PID list> obey the order of PIDs in my list or do I have to use separate kill processes to control the order in which processes get killed?

| improve this question | | | | |
  • 1
    What do you mean with "Some processes can't be killed before other processes"? – dr_ Feb 7 '18 at 8:56
  • 2
    I think he mean the case of daemon which span children processes. Killing children just make the daemon to create new children. Killing the parent now will (potentially) leave some new born children alive. – Giacomo Catenazzi Feb 7 '18 at 9:50

I doubt there's anything more than just sending the signal to each of the targets in turn. The POSIX definition for kill(1) is just that, so retrying seems it would be in violation of the specification:

The kill utility shall send a signal to the process or processes specified by each pid operand.

For each pid operand, the kill utility shall perform actions equivalent to the kill() function

Also, remember that not all signals cause processes to terminate, and some like SIGHUP (let alone SIGUSR1) may mean different things for different programs. There's no clear way for kill to know when to retry, but there surely exist programs that first send SIGTERM and later "retry" with SIGKILL.

Sending the signals in the order given would be the straightforward implementation, and that's what e.g. Bash's kill does:

$ strace -etrace=kill bash -c 'kill -0 33330 33339 33335 33332 33337' |& grep ^'kill('
kill(33330, SIG_0)                      = -1 ESRCH (No such process)
kill(33339, SIG_0)                      = -1 ESRCH (No such process)
kill(33335, SIG_0)                      = -1 ESRCH (No such process)
kill(33332, SIG_0)                      = -1 ESRCH (No such process)
kill(33337, SIG_0)                      = -1 ESRCH (No such process)
| improve this answer | | | | |

kill <PID list> simply sends the specified signal to the specified list of processes. Then the behavior of your system depends whether that particular process ignores or not that particular signal. By default, kill sends a TERM signal.

Assuming you're talking about SIGKILL here, this signal cannot be blocked or ignored. So kill -9 will kill the listed processes, unless for some reason the process is unresponsive (e.g. waiting for I/O on a blocked NFS).

| improve this answer | | | | |
  • Additionally, I can find no reference to the order in which the processes are signalled. But I'd be surprised if it was random rather than sequential in either direction. – Kusalananda Feb 7 '18 at 8:58

We can answer that question by simply looking at kill.c.

Basically we just:

  • list all processes with struct proc_processes ps = proc_open_processes(); then we filter that list by pids or processes names and send

  • kill_verbose(&ctl) to every found process, which is just simple kill(ctl->pid, ctl->numsig)

When process is killed with SIGKILL, it is terminated. From signal.h:

terminate   - kill the process, i.e. all threads in the group,
      similar to exit_group.  The group leader (only) reports
      WIFSIGNALED status to its parent.

So as you can see it is just simple "send message to process" command. Nothing fancy.

| improve this answer | | | | |

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.