This fixed it for me; no idea how/why it works:

codesign --sign - --force --preserve-metadata=entitlements,requirements,flags,runtime <path-to-binary>

Open a new terminal window/tab

The kill command will send a defined signal to a process with a given identity (PID):

kill -<signal> <pid>

Of course we can only kill processes we own, whereas root can kill all processes. See Wikipedia for a nice summary of computing signals.

Signals kill can send are listed in the manpage. The signal can be represented by name or by number. If no signal is given the default signal 15 resp. TERM is used.

All three commands below are therefore identical:

kill -9 1234
kill -KILL 1234
kill -SIGKILL 1234

The difference between SIGTERM and SIGKILL is the way an application may act on the signal:

• TERM: an application will be able to terminate, i.e. properly run a shutdown routine.
• KILL: the applications is stopped and killed immediately (which could lead to data loss or raising apport to report a presumed crash in some cases).

and kernel_task's pid is 0

They probably use the PID 0, because it is a reserved PID and as such you cannot send signals to the process.

I simply ran kill -9 0.

The *nix command kill is more or less a direct front-end for the kill system call. From the documentation of the system call:

If pid is zero:
      Sig is sent to all processes whose group ID is equal to the process group ID of the sender, and
      for which the process has permission; this is a variant of killpg(2).

In other words, in your case, kill -9 0 is just a fancy way to send the (fatal) signal to itself. (More about process groups.)

Why the heck does it just terminate the process that called the command

The kill (unless you have tweaked the shell settings) is a built-in shell command. In other words, the shell calls the kill syscall and that causes it to kill itself.

Try the same but with the external kill command, e.g. /bin/kill -9 0. In that case only the /bin/kill would be killed.

The problem was that I had a custom version bash installed at ~/.new_local/bin/ that I compiled myself. Deleting that so that it defaulted to homebrew install bash fixed this issue.

pid= with a space after it would set the pid variable to an empty string. The rest of that line would simply execute the pipeline and output the result (probably to the terminal unless it's being redirected). Since $pid is empty, kill later complains.

To capture the output of a command, use $(...), e.g.

pid=$( ps -ef | ... )

However, it's better to use pkill for what you're attempting to do:

pkill adminserver

See the pkill manual.

I would also avoid using the KILL signal if at all possible. See e.g. "When should I not kill -9 a process?".

You need to fake sign sbalert: ldid -S $(which sbalert) Hopefully this will fox your kill 9 problem. Sometimes you need to mv the binary after this command because ios caches.

It means that the application received a signal. Some signal could be handled by the applications, others, not. Signal 9 means that the application needs to be killed, it is not handled by the process, but by the Linux scheduler. The signal to terminate the process that is handled by the process is SIGTERM(15), but, if the process doesn't handle it property, then the process continues to live.

here are the major signals:

   Signal     Value     Action   Comment
   ──────────────────────────────────────────────────────────────────────
   SIGHUP        1       Term    Hangup detected on controlling terminal
                                 or death of controlling process
   SIGINT        2       Term    Interrupt from keyboard
   SIGQUIT       3       Core    Quit from keyboard
   SIGILL        4       Core    Illegal Instruction
   SIGABRT       6       Core    Abort signal from abort(3)
   SIGFPE        8       Core    Floating point exception
   SIGKILL       9       Term    Kill signal
   SIGSEGV      11       Core    Invalid memory reference
   SIGPIPE      13       Term    Broken pipe: write to pipe with no
                                 readers
   SIGALRM      14       Term    Timer signal from alarm(2)
   SIGTERM      15       Term    Termination signal
   SIGUSR1   30,10,16    Term    User-defined signal 1
   SIGUSR2   31,12,17    Term    User-defined signal 2
   SIGCHLD   20,17,18    Ign     Child stopped or terminated
   SIGCONT   19,18,25    Cont    Continue if stopped
   SIGSTOP   17,19,23    Stop    Stop process
   SIGTSTP   18,20,24    Stop    Stop typed at terminal
   SIGTTIN   21,21,26    Stop    Terminal input for background process
   SIGTTOU   22,22,27    Stop    Terminal output for background process

The exit status of a killed command should be the signal number plus 128. So you can use the exit status to find out which signal killed you process.

I tested it like this on Linux in the shell:

print_exit_status_for_signal () {
  (
    sleep 1000
    echo Exit staus $? = signal $(( $? - 128 ))
  ) &
  sleep 1
  killall "${1:+-$1}" sleep
}
print_exit_status_for_signal
print_exit_status_for_signal 15
print_exit_status_for_signal 9
print_exit_status_for_signal KILL
print_exit_status_for_signal TERM

EDIT: Note that a program can decide to exit with any¹ value (so you have to decide how far you trust the exit status to be the effect of a signal):

for i in $(seq 256); do
  sh -c "exit $i"
  echo Program exited with $?
done

Footnote 1: On my systems exit codes are represented as unsigned 8-bit numbers so they wrap at 256=0.