进程正在执行自己的代码
        |
        |  <- 内核投递一个信号（比如 SIGTERM）
        v
内核在进程【从内核态返回用户态】的时刻检查是否有未处理信号
        |
        +- 有 -> 强行插入执行信号处理函数
        |        处理完再回到原来被打断的位置继续
        +- 无 -> 正常返回

① 默认动作（Default）
   内核为每个信号规定了默认行为：Term（终止）、Core（终止并 dump）、
   Ign（忽略）、Stop（暂停）、Cont（继续）

② 捕获（Catch）
   注册一个信号处理函数，信号到来时执行它

③ 忽略（Ignore）
   设为 SIG_IGN，信号被丢弃

#include <signal.h>

void handler(int sig) {
    // 注意：这里能做的事情非常有限，见 §4
    write(STDERR_FILENO, "got signal\n", 11);
}

int main() {
    signal(SIGTERM, handler);      // 捕获
    signal(SIGPIPE, SIG_IGN);      // 忽略
    signal(SIGINT,  SIG_DFL);      // 恢复默认
    // ...
}

kill 1234          # 默认发 SIGTERM(15) —— 「请你退出」
kill -9 1234       # 发 SIGKILL(9)      —— 「立刻消失」

进程被 SIGKILL 杀掉时，来不及做的事情：
  ✗ 把内存里的缓冲区刷到磁盘（日志、数据文件可能丢最后几秒）
  ✗ 优雅关闭数据库连接（服务端要等 TCP 超时才回收，连接池被占）
  ✗ 从服务注册中心注销（其他服务继续往这里发请求 -> 502）
  ✗ 完成正在处理的请求（客户端收到连接重置）
  ✗ 释放分布式锁（其他实例要等锁过期）
  ✗ 删除 pid 文件、临时文件（残留垃圾）

# ✅ 标准做法
kill 1234                    # 先礼
for i in $(seq 30); do
    kill -0 1234 2>/dev/null || { echo "已退出"; exit 0; }
    sleep 1
done
echo "超时，强制杀"
kill -9 1234                 # 后兵

[Service]
KillSignal=SIGTERM        # 先发这个（默认值）
TimeoutStopSec=30         # 等 30 秒
# 超时后自动发 SIGKILL
KillMode=mixed            # 只给主进程发 TERM，超时后给整个 cgroup 发 KILL

spec:
  terminationGracePeriodSeconds: 30      # 默认 30 秒
  containers:
  - name: app
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "sleep 5"]   # 关键，见下

1. Pod 被标记为 Terminating
   v 【同时并行发生两件事】
2a. kubelet 执行 preStop hook，然后给容器 PID 1 发 SIGTERM
2b. Endpoint Controller 把这个 Pod 从 Service 的 endpoints 里摘掉
    -> 但各节点的 kube-proxy/ingress 更新 iptables 需要时间（几百 ms 到几秒）
   v
3. 等待 terminationGracePeriodSeconds（默认 30s）
   v
4. 时间到还没退出 -> SIGKILL

lifecycle:
  preStop:
    exec:
      # 什么都不做，只是等待，让 endpoints 变更传播到所有节点
      command: ["sh", "-c", "sleep 5"]

# ❌ shell 形式的 CMD，PID 1 是 sh，它不转发信号给子进程
CMD ./myapp
# 实际执行：/bin/sh -c "./myapp"
#   PID 1: sh          <- SIGTERM 发给它
#   PID 7: myapp       <- 真正的应用，收不到信号

# ✅ exec 形式，应用直接是 PID 1
CMD ["./myapp"]

# ✅ 或者在 shell 里用 exec 替换掉 shell 自己
CMD exec ./myapp

# 验证：进容器看 PID 1 是什么
docker exec -it mycontainer ps -ef
# UID   PID  PPID  CMD
# root    1     0  /bin/sh -c ./myapp      <- ❌ 有问题
# root    7     1  ./myapp

# 正确的应该是
# root    1     0  ./myapp                 <- ✅

// ✅ Go 服务的标准优雅关闭
func main() {
    srv := &http.Server{Addr: ":8080", Handler: mux}

    go func() {
        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            log.Fatal(err)
        }
    }()

    // 监听信号
    quit := make(chan os.Signal, 1)
    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
    <-quit
    log.Println("收到关闭信号，开始优雅关闭")

    // 给存量请求 25 秒处理完（要小于 terminationGracePeriodSeconds）
    ctx, cancel := context.WithTimeout(context.Background(), 25*time.Second)
    defer cancel()

    // Shutdown 会：① 立即停止 accept 新连接 ② 等已有请求处理完
    if err := srv.Shutdown(ctx); err != nil {
        log.Printf("优雅关闭超时: %v", err)
    }

    // 再关其他资源
    db.Close()
    redisClient.Close()
    log.Println("已退出")
}

preStop sleep (5s) + 应用 Shutdown 超时 (25s) < terminationGracePeriodSeconds (30s)
                                                 ^ 否则会被 SIGKILL 打断优雅关闭

kill -HUP $(cat /var/run/nginx.pid)      # nginx reload
nginx -s reload                           # 等价，nginx 自己封装的
systemctl reload nginx                    # systemd 里配的 ExecReload

kill -USR1 $(cat /var/run/nginx.pid)     # nginx: 重新打开日志文件

# /etc/logrotate.d/nginx
/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    postrotate
        kill -USR1 $(cat /var/run/nginx.pid)      # <- 关键
    endscript
}

1  ~ 31   传统信号（不可靠）—— 不排队，挂起期间重复到达会【合并成一次】
32 ~ 64   实时信号（可靠）  —— 排队，每次发送都会被单独处理，且有序

kill -l | head -4
#  1) SIGHUP   2) SIGINT   3) SIGQUIT  4) SIGILL
# ...
# 34) SIGRTMIN 35) SIGRTMIN+1 ...      <- 从这里开始是实时信号

时刻 t1: 内核给进程投递 SIGCHLD，进程正忙 -> 标记为 pending
时刻 t2: 又来一个 SIGCHLD -> 已经 pending 了，【直接丢弃】
时刻 t3: 又来一个 SIGCHLD -> 【又丢弃】
时刻 t4: 进程开始处理 -> 只执行【一次】处理函数

// ❌ 错误：只 wait 一次
void sigchld_handler(int sig) {
    wait(NULL);          // 只回收了一个，其余变僵尸
}

// ✅ 正确：循环 wait 直到没有可回收的
void sigchld_handler(int sig) {
    while (waitpid(-1, NULL, WNOHANG) > 0)
        ;                // WNOHANG 让它非阻塞，回收完就返回
}

// ❌ 不安全：printf 用了缓冲和锁
void handler(int sig) {
    printf("got %d\n", sig);      // 可能死锁
}

// ✅ 安全：write 是系统调用，无锁无缓冲
void handler(int sig) {
    const char msg[] = "got signal\n";
    write(STDERR_FILENO, msg, sizeof(msg) - 1);
}

// 方案一：self-pipe，处理函数只往管道写一个字节
static int sigpipe_fd[2];

void handler(int sig) {
    char c = (char)sig;
    write(sigpipe_fd[1], &c, 1);      // 唯一的操作，安全
}

// 主循环用 epoll 监听 sigpipe_fd[0]，在正常的事件循环里处理信号

// 方案二：signalfd（Linux 特有，更优雅）
sigset_t mask;
sigemptyset(&mask);
sigaddset(&mask, SIGTERM);
sigprocmask(SIG_BLOCK, &mask, NULL);      // 先阻塞，不走处理函数

int sfd = signalfd(-1, &mask, 0);
// 现在信号变成了一个可读的 fd，能直接扔进 epoll，
// 完全避开了异步信号安全的所有问题

# 经典场景：管道的下游提前退出
yes | head -1
# head 读到一行就退出并关闭读端
# yes 继续写 -> 收到 SIGPIPE -> 被终止
# 这正是期望的行为，否则 yes 会无限跑下去

客户端建立连接 -> 发请求 -> 【超时后主动断开】
                              v
服务端处理完，往 socket 写响应
                              v
                    对端已关闭 -> 收到 SIGPIPE -> 进程被杀

// C：忽略它，让 write() 返回 -1 并设 errno = EPIPE
signal(SIGPIPE, SIG_IGN);
// 之后在每次 write 后检查返回值和 errno

// Go：runtime 自动忽略了 SIGPIPE（对非标准输出的 fd）
// write 会返回 error（syscall.EPIPE），按普通错误处理即可
n, err := conn.Write(data)
if errors.Is(err, syscall.EPIPE) {
    // 客户端已断开，正常记录即可，不要当严重错误
}

ps -ef | grep nginx | awk '{print $2}'

特点：
  - 单向，要双向通信得建两个
  - 只能用于【有亲缘关系】的进程（父子、兄弟）
    因为它没有名字，只能靠 fork 时继承 fd 来共享
  - 写满会阻塞，读空也会阻塞（天然的流量控制）
  - 读端全部关闭后写入 -> SIGPIPE

mkfifo /tmp/mypipe
ls -l /tmp/mypipe
# prw-r--r-- 1 lhx lhx 0 Aug  6 22:00 /tmp/mypipe
# ^ 类型是 p (pipe)，大小永远是 0 —— 数据在内核里，不落盘

# 终端 A：写（会阻塞，直到有人读）
echo "hello" > /tmp/mypipe

# 终端 B：读
cat /tmp/mypipe
# hello

# 服务端：一个常驻循环，等命令
mkfifo /tmp/ctrl
while true; do
    if read -r cmd < /tmp/ctrl; then
        case "$cmd" in
            reload) reload_config ;;
            stop)   break ;;
        esac
    fi
done

# 客户端：任何进程都能发命令
echo "reload" > /tmp/ctrl

ls -l /var/run/docker.sock
# srw-rw---- 1 root docker 0 Aug  6 10:00 /var/run/docker.sock
# ^ 类型是 s (socket)

# 用 curl 通过 Unix socket 访问 Docker API
curl --unix-socket /var/run/docker.sock http://localhost/version

# 本机数据库连接优先用 socket
mysql -S /var/run/mysqld/mysqld.sock      # 而不是 -h 127.0.0.1
psql "host=/var/run/postgresql dbname=mydb"

进程 A 虚拟地址空间 -+
                     +--> 同一块物理内存
进程 B 虚拟地址空间 -+

A 写入 -> B 立刻可见，零拷贝，零系统调用

# System V（老，接口丑，但到处都有）
# shmget / shmat / shmdt / shmctl
ipcs -m                       # 查看当前的共享内存段
# key        shmid  owner  perms  bytes    nattch
# 0x00000000 32768  app    600    67108864 2

ipcrm -m 32768                # 手动删除（进程异常退出后可能残留）

# POSIX（新，推荐，本质是 tmpfs 文件）
# shm_open / mmap
ls -l /dev/shm/
# -rw------- 1 app app 67108864 Aug  6 22:00 myapp_cache
#             ^ 就是普通文件，可以直接 ls/rm/cp

# System V
ipcs -q
# msqid  owner  perms  used-bytes  messages

ipcs -s          # 查看 System V 信号量

# Shell 里最实用的跨进程互斥：flock
exec 9>/var/run/mytask.lock
flock -n 9 || { echo "已有实例在运行"; exit 1; }
# 锁在进程退出时【自动释放】（fd 关闭），比 pid 文件可靠

需要跨机器？        -> TCP / gRPC / 消息中间件
只在本机？
  +- 传大量数据、要极致性能？ -> 共享内存 + 信号量（复杂，慎用）
  +- 常规请求-响应？          -> Unix domain socket   <- 90% 的场景
  +- 只是发个控制指令？       -> 信号
  +- Shell 脚本之间？         -> 命名管道 或 直接用文件 + flock

package main

func main() {
    // ① 建立就绪状态标志，供健康检查读取
    var ready atomic.Bool
    ready.Store(true)

    mux := http.NewServeMux()
    mux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
        // liveness：只要进程活着就返回 200
        w.WriteHeader(http.StatusOK)
    })
    mux.HandleFunc("/readyz", func(w http.ResponseWriter, r *http.Request) {
        // readiness：关闭中返回 503，让 K8s 把流量摘掉
        if !ready.Load() {
            w.WriteHeader(http.StatusServiceUnavailable)
            return
        }
        w.WriteHeader(http.StatusOK)
    })

    srv := &http.Server{Addr: ":8080", Handler: mux}
    go srv.ListenAndServe()

    // v 接下面的代码块（同一个 main 函数，为便于讲解拆成两段）

    // ② 等待信号
    quit := make(chan os.Signal, 1)
    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
    sig := <-quit
    log.Printf("收到信号 %v，开始优雅关闭", sig)

    // ③ 第一步：先让健康检查失败，停止接收【新】流量
    //    这一步必须在 Shutdown 之前，且要留出传播时间
    ready.Store(false)
    time.Sleep(5 * time.Second)      // 等 endpoints 变更传播到所有节点

    // ④ 第二步：停止 accept，等存量请求处理完
    ctx, cancel := context.WithTimeout(context.Background(), 20*time.Second)
    defer cancel()
    if err := srv.Shutdown(ctx); err != nil {
        log.Printf("优雅关闭超时，仍有请求未完成: %v", err)
    }

    // ⑤ 第三步：按【依赖的反序】关闭资源
    consumer.Stop()        // 先停消息消费，不再产生新的 DB 操作
    db.Close()             // 再关数据库
    redisClient.Close()
    tracer.Shutdown(context.Background())   // 最后刷 trace 数据

    log.Println("已完全退出")
}

spec:
  terminationGracePeriodSeconds: 45      # 必须 > 5 + 20 + 关资源的时间
  containers:
  - name: app
    readinessProbe:
      httpGet: {path: /readyz, port: 8080}
      periodSeconds: 2                   # 探测要够频繁，否则摘流量慢
      failureThreshold: 1                # 一次失败就摘
    livenessProbe:
      httpGet: {path: /healthz, port: 8080}
      periodSeconds: 10
      failureThreshold: 3
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "sleep 5"]

preStop(5s) + ready=false 传播(5s) + Shutdown(20s) + 关资源(~3s) = 33s
                                                    < 45s ✅

FROM golang:1.23 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server

FROM gcr.io/distroless/static-debian12
COPY --from=build /app /app
USER 65532:65532
# ✅ exec 形式：应用直接成为 PID 1，能收到 SIGTERM
ENTRYPOINT ["/app"]
# ❌ 绝对不要写 ENTRYPOINT /app 或 CMD ./app（shell 形式）

# ① 确认容器里 PID 1 就是应用本身
kubectl exec -it mypod -- ps -ef
# PID  PPID  CMD
#   1     0  /app             <- ✅ 正确

# ② 实际测一次滚动更新，观察有没有 5xx
kubectl rollout restart deploy/myapp &
while true; do
    curl -s -o /dev/null -w "%{http_code}\n" https://myapp/api/ping
    sleep 0.1
done | sort | uniq -c
#  1823 200
#     0 502                   <- ✅ 零错误

# ③ 确认进程是被 TERM 正常退出，不是被 KILL
kubectl get events --field-selector reason=Killing
# 如果看到容器退出码是 137 (128+9) = 被 SIGKILL，说明超时了
# 正常优雅退出的退出码应该是 0