忽略sighup的核心是防止进程退出，而非彻底屏蔽信号，可通过nohup（忽略信号）、setsid（脱离会话）或trap（捕获清理）实现，选择取决于运行时长、资源回收需求及启动场景。
忽略终端断开产生的 SIGHUP，核心不是“彻底屏蔽信号”，而是让进程不因它退出——可通过信号忽略、会话脱离或捕获清理三种路径实现，选哪种取决于你是否需要资源回收、是否长期运行、是否在脚本中启动。
用 nohup 忽略 SIGHUP（最简快启）
nohup 的本质是让进程对 SIGHUP 执行 SIG_IGN（忽略动作），不改变会话归属，适合临时任务或快速验证：
- 写法：
nohup ./script.sh > run.log 2>&1 & - 必须显式重定向 stdout/stderr，否则默认写入
nohup.out，易覆盖或权限失败 - 进程 PPID 仍是当前 shell 的 PID，仍属原会话——它只是“听见了但装没听见”
- 不防 SIGTERM 或 SIGINT；若脚本本身含交互逻辑（如读 tty），可能异常退出
用 setsid 彻底脱离会话（更可靠长期运行）
setsid 创建新会话，使进程成为 init（PID 1）的子进程，从源头收不到终端发出的 SIGHUP：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 写法：
setsid ./monitor.sh > /var/log/monitor.log 2>&1（无需加 &） - 验证：执行后运行
ps -o pid,ppid,sess,tty -p $(pgrep -f monitor.sh)，PPID 应为 1，TTY 显示 ? - 比 nohup 更彻底，尤其适合运维工具、心跳服务、日志采集等跨夜任务
- 注意：某些依赖终端特性的程序（如调用
stty或检查/dev/tty的脚本）可能报错，需提前测试
用 trap 捕获并优雅清理（高并发脚本必备）
当你的脚本本身启动多个子进程（如并行 curl、后台 worker、临时锁文件），光忽略 SIGHUP 不够——必须捕获它并主动终止子进程、删锁、清临时目录：
- trap 必须放在脚本开头，且早于任何
&启动子任务：trap 'cleanup' HUP INT TERM - cleanup 函数里要显式 kill 子进程：
kill $(jobs -p) 2>/dev/null，再删锁、清/tmp、恢复终端设置 - systemd stop 默认发 SIGHUP（非 SIGTERM），没 trap 就等于静默崩溃
- 搭配 nohup 或 setsid 使用更稳妥，但 trap 是资源清理不可替代的一环
不推荐的误区与补救
有些做法看似有效，实则隐患明显：
-
command && disown：disown 只是从当前 shell 的 job 表移除，进程仍属原会话，SSH 断连时照样收 SIGHUP -
nohup setsid cmd &：冗余叠加，无实质增益，还可能干扰信号处理链路 - 只加
&不做任何处理：后台运行 ≠ 脱离终端，SIGHUP 照样触发默认退出 - 忘记重定向输出：stdout/stderr 继承终端 fd，断连后写操作可能阻塞或失败
