killall仅匹配进程短名称（如python3），不支持通配符或参数，易误杀；应优先用pkill -f匹配完整命令行，并先用-pgrel/-l预览，发SIGTERM而非-9以保障优雅退出。
killall 只匹配进程名，不匹配命令行参数
运行 python3 /opt/app/main.py 后，killall python3 会干掉所有叫 python3 的进程，包括你 IDE 里正在调试的脚本、终端里随手起的测试进程，甚至系统级的 python3 服务。因为 killall 只看 /proc/[pid]/comm 文件内容——它只存短名称（如 python3），不存路径或参数。
常见错误现象：killall nginx* 报错 “No such process”，killall 'nginx.*' 也无效——它根本不支持通配符或正则。
- 验证当前进程名：用
ps -eo comm,args | head -5对照comm列（短名）和args列（完整命令行） - 想精确终止某类启动方式？别用
killall，换pkill -f - 加
-v参数先试效果：killall -v python3会列出匹配到的进程数和每个是否成功发送信号 - 加
-i开交互模式：killall -i python3会逐个问你“kill 1234? (y/N)”
pkill -f 匹配完整命令行，适合带参数的场景
当你需要杀的是 “所有含 gunicorn 且监听 8001 端口的进程”，或者 “所有启动自 /var/www/myapp/ 目录的 node 进程”，pkill -f 是唯一靠谱的选择。
-f 表示匹配 /proc/[pid]/cmdline，也就是你敲进 shell 的那一整条命令（含空格、路径、参数）。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 务必先加
-l预览：pkill -lf "gunicorn.*8001"，确认 PID 和对应命令是否符合预期 - 注意 shell 转义：双引号内
.是字面量，.*才表示任意字符；写成pkill -lf 'gunicorn.*8001'更稳妥 - 限定用户更安全：
pkill -u www-data -f "php-fpm"不会误伤其他用户的同名进程 - 避免误匹配：
pkill -f "python3 server.py"可能意外匹配到grep "python3 server.py"自身，加-v或用pgrep -f先查再杀更可控
kill -9 不是万能解药，优先用 SIGTERM（15）
直接上 killall -9 python3 或 pkill -9 -f "worker" 很快，但代价是进程没机会关闭数据库连接、释放锁、保存临时状态——轻则日志断点，重则数据损坏。
SIGTERM（即 -15 或默认不加数字）才是设计用来优雅退出的信号。大多数正规服务（nginx、redis、gunicorn）都实现了对它的响应。
- 先发 TERM：
pkill -f "myapp" && sleep 2，再检查是否还活着 - 确认无响应后再补 KILL：
pkill -9 -f "myapp" - 用
kill -0 PID检测进程是否仍在运行（不发信号，只查状态） -
killall -TERM nginx和killall nginx效果一样，因为后者默认就是-TERM
真正难的不是发 kill，而是判断“该不该一起杀”
多个进程共用同一个 comm 名（比如都是 python3），但归属不同服务、不同用户、不同工作目录——仅靠名字无法区分。这时候硬批量杀，等于把婴儿和洗澡水一起泼出去。
例如 Web 应用的 worker 进程和后台定时任务都用 python3 启动，killall python3 会一锅端。
- 用
pgrep -f "keyword" -o提取最老的 PID，或-n提取最新的，缩小范围 - 结合
awk提取启动路径：ps -o pid,comm,args -p $(pgrep -f "myapp") | awk '$3 ~ /\/var\/www/ {print $1}' - 用
lsof -p PID -a -i :8001确认某个进程是否真在监听目标端口 - 复杂场景下，别图快，写个简短脚本做条件过滤，比一行命令拍脑袋强
