mjhjmtu

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?

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)

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).

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.