进程管理

ps aux
# USER  PID  %CPU %MEM    VSZ   RSS TTY  STAT  START   TIME COMMAND
# root    1   0.0  0.1 190972  6024 ?    Ss    Jun30   0:05 /usr/lib/systemd/systemd
#                                          ^^ 状态

# ps aux：BSD 风格，最常用
ps aux                          # 所有用户的所有进程
ps aux | head -1                # 看列标题

# ps -ef：Unix 风格
ps -ef                          # 所有进程，全格式

# ps aux（BSD 无短横线）vs ps -ef（Unix 带短横线）的区别：
#   ps aux  更偏“资源视角”：有 %CPU/%MEM/VSZ/RSS/STAT/START，适合看谁吃资源
#   ps -ef  更偏“血缘视角”：有 PPID（父进程）、C、STIME，适合追父子关系
#   记不住就都用 ps aux；要看 PPID 时用 ps -ef

# 查找特定进程
ps aux | grep nginx             # 查找 nginx 相关进程
ps -ef | grep nginx
pgrep -a nginx                  # 更干净：直接列出匹配的 PID+命令，不会匹配到 grep 自己

# 按用户查找
ps -u heiye                     # heiye 用户的进程

# 只看某进程的线程
ps -Lf -p 1234                  # 进程 1234 的所有线程

# 树形结构（父子关系）
ps auxf                         # 树形显示（BSD 风格）
ps -ejH                         # 另一种树形
pstree                          # 更直观的树形（推荐）
pstree -p 1234                  # 看进程 1234 的子进程树

top
# top - 10:30:15 up 30 days,  2:15,  2 users,  load average: 0.05, 0.10, 0.15
# Tasks: 156 total,   1 running, 155 sleeping,   0 stopped,   0 zombie
# %Cpu(s):  0.3 us,  0.2 sy,  0.0 ni, 99.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
# KiB Mem :  4046564 total,  152348 free, 1089756 used, 2804460 buff/cache
# KiB Swap:        0 total,        0 free,        0 used. 2677548 avail Mem
#
#   PID USER  PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
#  1234 root  20   0  162896   2212   1500 S  5.3  0.1   0:03.45 nginx

top -p 1234                    # 只看某个进程
top -u nginx                   # 只看某个用户的进程
top -H -p 1234                 # 看进程 1234 的所有线程
top -d 2                       # 每 2 秒刷新一次（默认 3 秒）
top -b -n 1 > top.log          # 批处理模式（输出一次后退出）

htop                            # 彩色、鼠标可点、可滚动
# 没有预装：apt install htop / yum install htop

sleep 100 &          # 后台跑
kill -9 %1; wait %1  # 用 SIGKILL(9) 杀；注意必须 wait %1（裸 wait 返回 0，取不到该任务退出码）
echo $?              # 137  = 128 + 9   → 生产里看到 137，十有八九是 OOM killer 干的

kill -l                          # 列出所有信号

kill 1234                        # 默认发送 SIGTERM（15），优雅终止
kill -15 1234                    # 显式发送 SIGTERM
kill -TERM 1234                  # 用名称

kill -9 1234                     # SIGKILL，强制杀（不留机会清理）
kill -KILL 1234

kill -HUP 1234                   # SIGHUP，常用于重新加载配置
kill -1 1234

# 按名称杀
killall nginx                    # 杀所有名为 nginx 的进程
pkill nginx                      # 同 killall
pkill -f "python app.py"         # 匹配完整命令行
pkill -u heiye                   # 杀某用户的所有进程（小心！）

# & — 放在后台运行
./long_task.sh &                 # 启动时直接放后台
# [1] 12345                      ← Shell 返回 [任务编号] PID

# Ctrl+Z — 暂停前台进程，放到后台
./long_task.sh
# 运行中...按 Ctrl+Z
# [1]+  Stopped   ./long_task.sh

# jobs — 查看后台任务
jobs
# [1]   Running    ./task1.sh &
# [2]-  Stopped    ./task2.sh
# [3]+  Stopped    ./task3.sh    ← + 表示当前任务，- 表示上一个

# bg — 让暂停的任务在后台继续
bg %1                            # %1 是 jobs 里看到的编号

# fg — 把后台任务调到前台
fg %1
# ./task1.sh 在终端里继续运行

# nohup 的基本用法
nohup ./long_running.sh &

# 默认输出到 nohup.out
# nohup: ignoring input and appending output to 'nohup.out'

# 指定输出文件
nohup ./long_running.sh > output.log 2>&1 &

# 场景：SSH 到服务器执行一个要跑 2 小时的脚本
# 直接跑：SSH 断掉脚本就停了
# 正确做法：

nohup ./deploy.sh > deploy_$(date +%Y%m%d_%H%M%S).log 2>&1 &

# 然后可以安全地关终端、断 VPN、合上笔记本

# 回来看结果
jobs                           # 同一个 Shell 里查
ps aux | grep deploy.sh        # 任意 Shell 里查
cat deploy_*.log               # 看输出

# 场景：任务已经跑起来了才想起没 nohup，用 disown 补救
./long_task.sh &        # 已经在后台
disown -h %1            # 之后关终端，它不会被 SIGHUP 干掉

# setsid：一步到位脱离终端（常用于把任务真正“扔出去”）
setsid ./long_task.sh > out.log 2>&1 < /dev/null
# 注意：setsid 后进程不再是当前 shell 的子任务，jobs 里看不到，要用 ps/pgrep 找

uptime
# 10:30:15 up 30 days, 2:15, 2 users, load average: 0.05, 0.10, 0.15
#                                                  1分钟   5分钟   15分钟

cat /proc/loadavg
# 0.05 0.10 0.15 1/156 12345

# 查看 CPU 核数
nproc                            # 逻辑核心数
grep -c processor /proc/cpuinfo

# 举例：4 核机器，load 0.5 = 很空闲，load 8 = 严重过载

pgrep nginx                 # 列出所有 nginx 的 PID
pgrep -a nginx              # 连命令行一起列出（-a = 全命令）
pgrep -f "python app.py"    # -f 匹配完整命令行（默认只匹配进程名）
pgrep -u www-data           # 某用户的进程
pgrep -n nginx              # 最新启动的那个；-o 则是最老的

pkill nginx                 # 按名杀（默认 SIGTERM）
pkill -f "python app.py"    # 按完整命令行杀
pkill -9 -u baduser         # 杀某用户全部进程（危险，先 pgrep 看清再动手）

lsof -p 1234                # 进程 1234 打开的所有文件/socket
lsof -i :8080               # 哪个进程占用了 8080 端口（排查“端口被占用”必备）
lsof -i tcp:443             # 指定协议
lsof /var/log/app.log       # 谁在占用这个文件
lsof -u nginx               # 某用户打开的文件
lsof +D /data               # 谁在占用 /data 目录下的文件（卸载不了盘时用）

# 经典坑：删了大日志文件但磁盘没释放 → 因为进程还开着这个文件句柄
lsof | grep deleted         # 找到还占着已删除文件的进程，重启它才真正释放空间

ls -l /proc/1234/cwd        # 进程的当前工作目录（软链）
ls -l /proc/1234/exe        # 进程对应的可执行文件（软链，删了程序还能看到原路径）
cat  /proc/1234/cmdline | tr '\0' ' '   # 完整启动命令（参数用 \0 分隔）
cat  /proc/1234/environ | tr '\0' '\n'  # 进程的环境变量（排查“为啥读不到某变量”）
ls   /proc/1234/fd/          # 打开的文件描述符（0/1/2 就是 stdin/out/err）
cat  /proc/1234/status       # 状态、内存、线程数、PPID、UID 等一览
cat  /proc/1234/limits       # 该进程的 ulimit 限制（排查“too many open files”）

crontab -e                  # 编辑当前用户的定时任务（首次会让你选编辑器）
crontab -l                  # 查看当前用户的任务
crontab -r                  # 删除当前用户的所有任务（危险，无二次确认）
crontab -u www -l           # 查看指定用户的任务（需 root）

┌─────────── 分钟 (0-59)
│ ┌───────── 小时 (0-23)
│ │ ┌─────── 日   (1-31)
│ │ │ ┌───── 月   (1-12)
│ │ │ │ ┌─── 星期 (0-7，0 和 7 都是周日)
│ │ │ │ │
* * * * *  要执行的命令

# 例子
0 3 * * *      /opt/backup.sh              # 每天凌晨 3:00
*/5 * * * *    /opt/check.sh               # 每 5 分钟
0 0 * * 0      /opt/weekly.sh              # 每周日 00:00
30 2 1 * *     /opt/monthly.sh             # 每月 1 号 2:30
0 9-18 * * 1-5 /opt/workhour.sh            # 工作日 9-18 点每个整点
@reboot        /opt/on_boot.sh             # 开机时执行一次（@daily/@hourly 同理）

/etc/crontab                # 系统主 cron 表：分 时 日 月 周 用户 命令
/etc/cron.d/                # 放置额外 cron 片段（软件包常往这里丢）
/etc/cron.{daily,weekly,monthly}/   # 丢脚本进去就按频率跑（由 run-parts 驱动）

# 坑 1：cron 的环境极简，PATH 很短 → 脚本里命令“找不到”
#   → 命令写绝对路径，或在脚本开头自己 export PATH
# 坑 2：% 在 crontab 里是特殊字符（表示换行）→ date +\%Y 里的 % 必须转义
0 3 * * * /opt/backup.sh > /var/log/backup_$(date +\%Y\%m\%d).log 2>&1
# 坑 3：默认执行结果会邮件发给用户，没配 MTA 就堆积 → 加 >log 2>&1 或 >/dev/null 2>&1
# 坑 4：时区 —— cron 按系统时区跑，确认 `timedatectl` 时区没错
# 调试：先跑 `bash -c 'env - /opt/backup.sh'` 模拟 cron 的干净环境，看会不会挂

# /etc/systemd/system/backup.service  —— 定义“做什么”
[Unit]
Description=Nightly backup

[Service]
Type=oneshot
ExecStart=/opt/backup.sh

# /etc/systemd/system/backup.timer  —— 定义“何时做”
[Unit]
Description=Run backup daily at 03:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true          # 关机错过了，开机后补跑一次

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now backup.timer    # 启用并启动
systemctl list-timers                  # 看所有定时器：下次何时跑、上次跑没跑
journalctl -u backup.service           # 直接看任务的执行日志（cron 给不了这么方便）

# 找 Java 进程
PID=$(pgrep -f "java.*app.jar")

# 看该进程的线程
top -H -p $PID
# 或
ps -Lf -p $PID

# 看哪个线程吃 CPU 最多
top -H -p $PID      # 按 P 排序，记下高 CPU 的线程 PID
# 转成十六进制
printf "%x\n" 12345
# 用 jstack 看这个线程在干嘛
jstack $PID | grep -A 20 0x3039

# 不要用 kill -9！也不要 systemctl restart（会中断连接）
# 优雅地重新加载配置，不中断现有连接

# 方法 1：SIGHUP
kill -HUP $(cat /var/run/nginx.pid)

# 方法 2：通过 systemctl
systemctl reload nginx

# 方法 3：nginx 自身的命令
nginx -s reload

# 确认配置生效
nginx -t                         # 先测试配置语法
nginx -s reload                  # 通过

# 找出僵尸进程
ps aux | grep 'Z'
# 或
top -b -n 1 | grep zombie

# 僵尸进程的 PPID 就是它的父进程
ps -o ppid= -p <zombie_pid>

# 解决方法：让父进程回收子进程
# 如果父进程是服务进程（如 nginx），正常 reload/restart 即可
# 如果父进程是写坏的脚本，kill 它然后 init（PID=1）会回收僵尸

# 僵尸少的话无害（占 PID 但不占内存）
# 大量僵尸说明父进程有 bug，需要修复