在Linux系统的进程管理中，信号是内核与进程之间通信的重要方式，其中SIGTERM和SIGKILL是开发者在终止进程时最常接触的两种信号。很多场景下我们会通过kill命令操作进程，但如果不了解两种信号的底层逻辑，很容易出现进程无法正常停止、或者强制终止后留下残留资源的问题。比如运行中的数据库进程如果被直接发送SIGKILL，可能来不及把内存中的脏数据刷入磁盘，导致数据损坏；而一些陷入死循环的进程如果只发送SIGTERM，可能无法响应，需要配合SIGKILL才能终止。
SIGTERM 信号的特性与处理机制
SIGTERM是编号为15的信号，也是kill命令默认发送的信号类型。它的设计初衷是给进程一个「优雅退出」的机会，属于可捕获、可阻塞、可忽略的软信号。当进程收到SIGTERM信号时，内核会中断进程当前的执行流程，跳转到进程预先注册的信号处理函数执行逻辑，处理函数执行完成后，进程可以选择正常退出，也可以选择忽略这个信号继续运行。大部分遵循POSIX标准的程序都会默认处理SIGTERM信号，执行资源释放、状态保存等清理操作后再退出。
我们可以通过一段简单的C语言代码来观察SIGTERM的处理过程。下面的代码注册了SIGTERM的信号处理函数，收到信号时会打印提示信息并正常退出，同时我们也可以通过signal函数或者更推荐的sigaction函数来绑定处理逻辑。需要注意的是，SIGTERM的处理函数不能执行太长时间的操作，否则如果进程同时收到多个SIGTERM信号，可能会出现逻辑异常。
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
// SIGTERM信号处理函数
void sigterm_handler(int signo) {
printf("收到SIGTERM信号，开始执行清理操作...\n");
// 模拟资源释放：关闭文件、断开连接等
sleep(1);
printf("清理完成，进程正常退出\n");
exit(0);
}
int main() {
// 注册SIGTERM信号的处理函数
struct sigaction sa;
sa.sa_handler = sigterm_handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = 0;
sigaction(SIGTERM, &sa, NULL);
printf("进程启动，PID: %d\n", getpid());
// 让进程保持运行，等待信号
while(1) {
sleep(1);
}
return 0;
}
如果把上面这段代码编译运行后，在另一个终端执行kill 进程PID，就会触发我们注册的处理函数，看到清理操作的输出。如果我们不注册处理函数，进程收到SIGTERM时也会执行默认的退出逻辑，不过不会执行自定义的清理操作。另外SIGTERM是可以被阻塞的，我们可以通过sigprocmask函数把SIGTERM加入进程的信号阻塞集，这样进程在阻塞期间即使收到SIGTERM也不会被处理，直到解除阻塞后才会响应。
SIGKILL 信号的强制终止逻辑与限制
SIGKILL是编号为9的信号，它的最大特点是不可捕获、不可阻塞、不可忽略，属于系统级的强制终止信号。当进程收到SIGKILL信号时，内核不会给进程任何执行自定义逻辑的机会，而是直接剥夺进程的运行权限，回收进程占用的所有系统资源，包括内存、打开的文件描述符、网络连接等，然后直接销毁进程。这也是为什么当我们用kill -9 进程PID命令时，几乎不会有进程能够抵抗终止的原因。
不过SIGKILL并不是万能的，它也有无法立即终止进程的特殊场景。如果进程处于不可中断睡眠状态（比如正在等待磁盘I/O、等待硬件设备响应），此时发送SIGKILL信号，进程不会立即被终止，而是会等到进程从不可中断睡眠状态唤醒后，才会被内核处理SIGKILL信号并终止。这种状态下的进程通常会在ps命令的输出中显示为D状态，也就是不可中断睡眠状态，此时即使发送SIGKILL也无法立即生效，只能等待I/O操作完成或者系统层面解决问题。
我们可以通过一段简单的代码来验证SIGKILL的不可捕获特性。下面的代码尝试注册SIGKILL的处理函数，运行后会发现注册失败，因为内核不允许进程捕获SIGKILL信号，这是系统层面的硬性限制，目的是为了防止恶意进程通过捕获SIGKILL来逃避终止，导致系统资源被长期占用。
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <errno.h>
void sigkill_handler(int signo) {
// 这段代码永远不会被执行
printf("尝试捕获SIGKILL信号\n");
}
int main() {
// 尝试注册SIGKILL的处理函数，会失败
if (signal(SIGKILL, sigkill_handler) == SIG_ERR) {
perror("无法捕获SIGKILL信号");
printf("错误原因: %s\n", strerror(errno));
}
printf("进程启动，PID: %d\n", getpid());
while(1) {
sleep(1);
}
return 0;
}
运行上面的代码后，执行kill -9 进程PID，会发现进程直接被终止，不会执行任何自定义逻辑，同时终端会输出注册SIGKILL处理函数失败的错误信息，提示操作不被允许。另外需要注意的是，SIGKILL虽然能快速终止进程，但会带来资源泄漏的风险，比如进程打开的临时文件没有被删除、申请的共享内存没有被释放、网络连接没有正常断开，这些残留资源需要手动清理，否则会占用系统资源。
两种信号的选择策略与常见场景
在实际的进程管理场景中，我们需要根据进程的类型和当前的状态来选择使用哪种信号。优先推荐先发送SIGTERM信号，给进程足够的时间执行清理操作，等待几秒后如果进程仍然没有退出，再发送SIGKILL信号强制终止。这种组合方式既能保证大部分正常进程优雅退出，避免数据丢失和资源泄漏，也能处理那些无响应或者陷入异常的进程，保证进程管理的效率。
不同的服务类型适合的信号策略也有差异。比如运行中的数据库服务（MySQL、PostgreSQL等）、消息队列服务（RabbitMQ、Kafka等），这些服务通常会在内存中缓存数据，并且有持久化机制，优先发送SIGTERM可以让它们把内存中的脏数据刷入磁盘，关闭所有的客户端连接，避免数据损坏。而如果是一些自定义的脚本进程、陷入死循环的测试进程，或者已经确认无状态的后台任务进程，如果发送SIGTERM后没有响应，可以直接发送SIGKILL快速终止，减少等待时间。
我们还可以通过脚本实现自动的信号选择逻辑，比如下面的Shell脚本会先发送SIGTERM给指定进程，然后每隔1秒检查进程是否还存在，最多等待5秒，如果5秒后进程仍然存在，就发送SIGKILL强制终止。这种脚本可以放在服务停止的脚本中，实现自动化的优雅停止逻辑，不需要手动判断进程状态。
#!/bin/bash
PID=$1
TIMEOUT=5
COUNT=0
if [ -z "$PID" ]; then
echo "请提供进程PID"
exit 1
fi
# 先发送SIGTERM信号
echo "发送SIGTERM信号给进程 $PID"
kill -15 $PID
# 等待进程退出，最多等待TIMEOUT秒
while [ $COUNT -lt $TIMEOUT ]; do
if ! ps -p $PID > /dev/null 2>&1; then
echo "进程 $PID 已正常退出"
exit 0
fi
sleep 1
COUNT=$((COUNT + 1))
echo "等待进程退出，已等待 $COUNT 秒"
done
# 超时后发送SIGKILL信号
echo "进程 $PID 未在 $TIMEOUT 秒内退出，发送SIGKILL强制终止"
kill -9 $PID
# 再次检查是否终止成功
sleep 1
if ! ps -p $PID > /dev/null 2>&1; then
echo "进程 $PID 已强制终止"
else
echo "无法终止进程 $PID，请检查进程状态"
fi
另外在容器化场景中，比如Docker容器的停止逻辑，默认也是先发送SIGTERM给容器内的主进程，等待10秒后如果进程还没有退出，就发送SIGKILL终止容器。如果我们的容器主进程没有处理SIGTERM信号，就会导致容器停止时直接被强制终止，可能留下残留数据。因此在编写容器化的服务时，一定要确保主进程能够正确处理SIGTERM信号，或者在Dockerfile中通过STOPSIGNAL指令指定容器停止时发送的信号类型，适配服务的信号处理逻辑。