kill默认发送SIGTERM（15号信号），允许进程优雅退出并执行清理；而kill-9发送SIGKILL（9号信号），强制终止且无法捕获或清理。
kill -9 不是第一选择，先试 kill 默认信号
绝大多数情况下，直接上 kill -9 是在跳过进程的自我清理逻辑。真正该做的，是先发 SIGTERM（即不带参数的 kill PID），给进程几秒时间关文件、写缓存、释放锁。很多 Python 脚本、Node 服务、数据库客户端都注册了这个信号的处理函数，强行跳过会导致 nohup.out 日志截断、临时文件残留、数据库连接未释放等问题。
实操建议：
- 用
ps aux | grep my_script.py或pgrep -f "my_script.py"找到 PID - 执行
kill 12345（假设 PID 是 12345） - 等 3–5 秒，再用
ps -p 12345确认是否退出；还在就继续下一步
nohup 启动的任务为什么 kill 不掉？检查父进程和会话归属
用 nohup python task.py > log.txt 2>&1 & 启动的任务，看似独立，其实仍属于当前 shell 会话。如果终端意外断开或 ssh 连接中断，它可能已脱离原会话、变成孤儿进程，PID 也未必是你看到的那个。此时只靠 kill 可能找不到目标，或者杀掉的是子进程而非主进程。
排查要点：
- 用
ps -eo pid,ppid,sess,comm,args | grep task.py查看进程的父 PID（ppid）和会话 ID（sess） - 若
ppid是 1，说明已成孤儿，kill仍有效；但若它挂在某个已死的会话下，pkill -P或kill -- -（负号表示会话组）更可靠 -
nohup不等于“完全脱离”，它只是忽略SIGHUP，不代表不能被SIGTERM或SIGKILL终止
pkill 和 killall 比手动找 PID 更快，但匹配要精准
当你记不清 PID，又不想翻 ps 输出时，pkill 和 killall 是快捷入口。但它们靠名字匹配，容易误伤——比如 pkill python 会干掉所有 Python 进程，包括你正在调试的 ipython 或 vscode-server。
安全用法：
- 加
-f选项匹配完整命令行：pkill -f "my_long_task.py" - 加
-u $USER限定用户：pkill -u $(whoami) -f "task.py" - 先用
-l预览：pkill -f "task.py" -l列出匹配项，确认无误再删 -
killall默认只匹配进程名（argv[0]），对python script.py类型无效，不如pkill -f灵活
强制结束之后，别忘了清理残留资源
kill -9 的代价不是“快”，而是“没机会收尾”。常见后遗症包括：临时文件卡在 /tmp、端口被占（Address already in use）、锁文件未清除（如 .lock 或 SQLite 的 shm/wal 文件）、日志文件权限错乱。
收尾动作建议：
- 检查对应端口是否释放：
lsof -i :8000或ss -tuln | grep :8000 - 查看
/tmp下是否有脚本生成的临时文件：ls -lt /tmp/ | head -10 - 如果用了数据库或文件锁，手动删掉残留锁文件（路径通常在脚本里硬编码或文档中有说明）
- 重定向日志的
output.log可能最后几行缺失，别全信它的 EOF 状态
真正难的不是“怎么杀”，而是判断“该不该杀”和“杀完还剩什么”。一个没清理干净的 kill -9，可能比不杀更麻烦。
