Linux进程组、控制终端与守护进程：网络服务为何总被SIGHUP杀掉

如果你在一台Linux服务器上跑网络服务，大概率经历过这种诡异的事：程序在终端前台跑得好好的，能监听端口、能正常回包，可只要你退出登录、或者随手关掉终端窗口，这个服务就像被抽掉了地基一样瞬间没了。我曾经因为这个现象查了大半天代码，最后发现真正杀死服务的不是业务逻辑，而是Linux里一套看不见的进程间关系：进程组、会话、控制终端。这三个概念平时就藏在ps命令的输出里，不起眼，却直接决定你的服务能不能长期活着。

这篇文章围绕Linux网络场景下最实用的两个主题展开：进程间关系（进程组、会话、控制终端）和守护进程。我会用一次真实排查过程把主线串起来——从“关掉终端服务就死”的现象出发，讲到内核为什么要发SIGHUP；然后拆解进程组、会话、控制终端这三层结构；接着手写一个标准守护进程，每一行代码都讲清楚为什么；最后聊nohup、setsid、systemd这些现成工具的取舍与调试中踩过的坑。适合刚接触Linux服务部署的读者，也适合写过服务但总被“进程消失”问题困扰的人。

1. 先看现象：关掉终端，网络服务为什么会“陪葬”

1.1 一次让人懵掉的排查

我最早被这个问题坑，是在给一个自研的TCP服务做联调的时候。服务本身不复杂：监听一个端口，收到什么数据就原样返回什么，方便测试。代码在服务器上编译完，终端前台一跑，一切正常，用客户端连上去，回显也没问题。我以为万事大吉，退出SSH登录准备去吃个饭。回来后想再测一次，端口直接连不上。重新登进服务器一看，进程没了。

ps都查不到，连僵尸进程都没有。也就是说它不是因为段错误崩溃了，也不是被OOM Killer杀了，而是被什么东西“干干净净地”清掉了。我当时的排查思路是先翻dmesg，确认没有内存相关的击杀记录，然后查crontab有没有定时任务在作祟，又看防火墙策略、看系统日志，全部对不上。

后来有个同事路过，问了一句：“你是不是直接在终端前台跑的，没加nohup？”我说是啊。他说那就没辙，你退出登录的时候，终端一断开，内核会给这个会话里的进程发SIGHUP信号，你的服务没处理这个信号，默认动作就是终止。就这么一句话，解开了我卡了一下午的谜。核心不在你的代码，在于进程和终端之间那层“依附关系”。

1.2 ps命令里的“户口本”

为了看清楚这层关系，他让我跑了一条命令，把所有进程的“户口”打出来：

ps -eo pid,ppid,pgid,sid,tty,stat,comm

输出大概长这样（具体PID因机器而异）：

PID PPID PGID SID TTY STAT COMMAND 1200 1 1200 1200 ? Ss systemd 2300 1200 2300 2300 pts/0 Ss bash 3400 2300 3400 2300 pts/0 S+ demo_server

每一列都有讲究：

• PID：进程自己的编号。
• PPID：父进程编号，相当于“谁把我生出来的”。
• PGID：进程组编号，“我和哪些进程编在一个组”。
• SID：会话编号，“我属于哪个会话这个大组织”。
• TTY：控制终端，“我绑在哪条电话线上”。如果显示?，说明没有控制终端。
• STAT：进程状态。S表示可中断睡眠，s表示这个进程是会话组长，+表示它属于前台进程组。

看到demo_server那行了吗？它的TTY是pts/0，说明它绑定在一个伪终端上，而这个伪终端正是SSH登录时分配出来的。SSH会话一断开，伪终端就会被关闭，终端上那些进程就得面对SIGHUP的命运。所以问题不是“程序写错了”，而是“程序活错了地方”——它把自己挂在了会消失的终端上。

1.3 SIGHUP：从电传终端时代留下的规矩

SIGHUP全称是hang up，中文叫“挂断”。这个信号的来历可以追溯到串行终端时代：当你把电话线从猫上拔下来，终端连接断开，内核就向连接在这个终端上的相关进程发SIGHUP。到了今天，触发场景依然忠实于历史：终端连接断开、SSH退出、伪终端关闭，都会产生它。

关键点在于，绝大多数普通程序不会去捕捉SIGHUP，而它的默认动作是终止进程。Linux没有针对你的服务有什么恶意，它只是在遵守一条几十年不变的“行规”：终端都没了，赖在终端上的进程也就没有继续存在的意义了。这也是为什么后来的守护进程概念如此重要——一个合格的长期服务，必须主动切断和终端的依附关系，而不是被动祈祷终端别关。

到这里，表面原因找到了。但要彻底解决类似问题，光知道“有SIGHUP这个东西”是不够的，你得理解Linux到底是怎么把进程组织起来的：进程组管“跟谁一起行动”，会话管“整个阵营归谁”，控制终端管“和外界怎么通信”。下面逐个拆开讲。

2. 进程组：Linux给进程发的“班组编制”

2.1 什么是进程组

进程组（process group）是一组进程的集合，共享同一个PGID。每个进程都属于且只属于一个进程组。你可以把它想成部队里的班组编制：一个班几个人，干同一摊活，发命令的时候对整个班发，而不是一个个点名。

进程组是怎么产生的？很简单，fork()出来的子进程默认继承父进程的PGID。所以你在shell里敲一条管道命令，比如cat access.log | grep "error" | wc -l，这三个进程通常都在同一个进程组里，PGID往往就是cat进程的PID。它们是一个流水线上的三个工位，天然应该被当成一个整体来管理。

查看进程组很简单：

ps -eo pid,pgid,sid,comm | sort -k2

你会发现，很多在逻辑上属于同一批的任务，PGID是相同的。尤其是当你用shell的作业控制（job control）功能时，这种分组就更明显了：每个作业都会被shell放进独立的进程组。

2.2 信号按组发放：kill的负数参数

进程组最实际的价值，是解决了“给一批进程发信号”的粒度问题。如果只能给单个PID发信号，你在清理服务的时候就得一个个数进程号，数完了还可能有新fork出来的子进程漏网。有了进程组，一条命令就能端掉一窝：

kill -TERM -1234

注意前面那个负号。给负的PGID发信号，就是向整个进程组广播。这比写脚本遍历pstree要干净得多。

我在清理临时测试服务时经常这么干：

kill -TERM -$(ps -o pgid= -p 3400 | tr -d ' ')

先用pgrep找到目标进程PID，再用ps取出它的PGID，然后对整个组发送TERM信号。信号默认动作是终止，如果进程不响应TERM，再补一个KILL，也是按组发。这套操作在管理那种“一个主进程带一堆子进程”的服务时特别顺手。

2.3 作业控制：shell每天都在用进程组

交互式shell是进程组机制最大的用户。你在bash里运行一个前台程序，bash会把这个程序放到一个新建的进程组里，并把它设为“前台进程组”；你按Ctrl+Z挂起它，再用bg放到后台，它就成了一个后台进程组。一个终端同时可以有多个后台进程组，但前台进程组只有一个——只有它才能从终端读取输入。

这就引申出终端信号的传播路径：你在键盘上按Ctrl+C，终端驱动产生的是SIGINT，这个信号不是发给PID为1或者发给某个具体进程的，而是发给当前前台进程组的所有成员。按Ctrl+Z发出的SIGTSTP同理。所以你的服务如果是前台跑着的，Ctrl+C一按，整个组一起收到信号。

理解这一点，对排查“为什么我的服务明明有信号处理函数，却还是死了”很有帮助。很多新手以为自己写个signal(SIGINT, handler)就万事大吉，但如果你跑的是管道里的某个子进程，它收到信号时，旁边的同组进程可能先崩溃，导致管道破裂，服务照样异常退出。要处理这类问题，先看进程组，再谈信号处理。

2.4 一个容易踩的坑：setpgid的调用限制

如果你在代码里需要把进程挪到别的进程组，用的是setpgid()。这个函数看起来简单，但有几条硬性限制：

• 只能修改自己或者自己子进程的组。
• 子进程只要已经执行过exec()，父进程就不能再改它的组了（子进程自己exec之后仍然可以改自己的组）。
• 目标进程不能是会话组长。
• 不允许跨会话操作。

这也是为什么shell在创建作业时，经常让子进程自己调用setpgid(0,0)来“自报家门”，而不是等父进程来安排——时机上反而是子进程更可控。我见过有人在父进程fork()之后立刻调setpgid，以为没问题，结果因为中间插了别的初始化导致时机太晚而失败。规避办法就是让子进程在fork()回来之后，立即自行设置。

3. 会话：比进程组更大的“组织单元”

3.1 会话是怎么长出来的

会话（session）是进程组的上层容器：一个会话包含一个或多个进程组，进程组只能属于一个会话。每次登录（不管是本地终端还是SSH），系统都会创建一个新会话，登录shell就是会话组长。会话ID（SID）就等于会话组长进程的PID。

你运行ps axjf，能看到系统里的会话结构：

ps axjf PPID PID PGID SID TTY TPGID STAT UID COMMAND 1 1200 1200 1200 ? -1 Ss 0 systemd 1 2300 2300 2300 pts/0 2300 Ss 1000 bash 2300 3400 3400 2300 pts/0 3400 S+ 1000 demo_server

bash是会话组长，demo_server和它的子进程都在这个会话里，只是处在不同的进程组。会话存在的意义，就是把“从一次登录开始到退出登录为止”的所有活动圈在一起，方便统一管理终端和信号。

新会话只能由setsid()系统调用创建。调用setsid()的进程会成为新会话的组长、新进程组组长，并且脱离原来的控制终端（如果有）。但注意一个前提：如果调用者本身就是进程组组长，setsid()会直接返回失败。这个限制是守护进程编程里“第一次fork”存在的最直接原因，后面写守护进程时会详细说。

3.2 控制终端：会话与外界的电话线

一个会话最多只能有一个控制终端。会话组长第一次打开一个终端设备时，这个终端就成为该会话的控制终端。有了控制终端，才会有前面说的那些信号行为：Ctrl+C发SIGINT、Ctrl+\发SIGQUIT、Ctrl+Z发SIGTSTP，全部经由终端驱动送给前台进程组。

控制终端还有一层作用：它是进程访问“前台还是后台”的裁判。后台进程如果尝试从控制终端读取数据，内核会发SIGTTIN把它停住；如果尝试写，会发SIGTTOU。这就是为什么一个脚本跑到一半被放到后台，反而卡住不动的根本原因——它在等待终端输入，但没有资格去读。

反过来，如果一个会话没有控制终端，这一切“终端信号”都不存在。你的服务就不会因为某个终端上的Ctrl+C而意外死掉。这其实是网络服务梦寐以求的状态。但注意，仅仅是“没有终端”还不够，关键在于进程是否还残留着终端相关的fd或会话关系。后面手写守护进程的那一步“重定向标准描述符”，目的就是把这层关系彻底擦干净。

3.3 孤儿进程组：组织没了会发生什么

会话里还有一个容易被忽略的边界情况：孤儿进程组。定义是：组内每个成员的父进程，都不在这个会话的其他进程组里（也就是说父进程要么退出了，要么在别的会话）。最典型的就是父进程退出后，子进程被1号进程收养。

为什么孤儿进程组值得警惕？因为当组内存在停止状态（比如被SIGTSTP挂起）的进程时，这个组会收到SIGHUP，紧接着又收到SIGCONT。内核的逻辑是：你们已经没有“组织”接管了，如果还停着，那就先通知你挂断，再让你继续跑起来，让你自己去处理后续。

这个机制和守护进程有深层关系。守护进程本质上是“主动成为孤儿”——父进程退出，自己被收养，同时切断和终端的联系，自己一个人在新的会话里长期运行。懂得了孤儿进程组的处理规则，你就明白为什么守护进程要自己管理好停止/继续的状态，不能指望控制终端来唤醒自己。

4. 守护进程的本质：摆脱终端束缚的“长期工”

4.1 守护进程长什么样

守护进程（daemon）通常有这些特征：

• 在后台运行，没有控制终端，TTY一栏显示?。
• 生命周期长，随系统启动、随系统关闭，不看任何终端脸色。
• 标准输入、标准输出、标准错误一般被重定向到/dev/null或日志文件。
• 启动后不依赖启动它的shell环境，工作目录、umask都是自己说了算。

你系统里那些网络服务，绝大多数都是这种形态。它们在系统启动阶段就被拉起来，绑好端口，然后安静地等待请求，既不理会终端的Ctrl+C，也不会因为你退出SSH而消失。

判断一个进程是不是守护进程，最直接的办法还是ps：

ps -eo pid,ppid,pgid,sid,tty,stat,comm

注意看TTY列，凡是显示?的，基本都是不依赖终端的进程。再看PPID，很多守护进程的PPID是1，说明它已经被“孤儿收养机制”纳入了系统初始化进程的管辖。

4.2 网络服务和守护进程为什么天生一对

网络服务和守护进程几乎绑定在一起，原因很朴实：网络服务靠的是监听端口、接受连接，它必须“一直活着”。如果一个监听端口的服务活在某个SSH会话里，那么用户退出登录的瞬间，服务就跟着报销了——这显然不能接受。

更深一层是“会话的边界”。交互式会话天生是给人用的：用户来了，开一个会话；用户走了，会话结束，里面的前台任务一起结束。但网络服务不是给人用的，它是给其他机器上的请求用的，它不应该绑定在任意一个“人”的会话周期里。

另外，网络服务经常需要处理多连接，父进程可能fork出多个子进程分别服务不同的客户端。在这种情况下，进程组和会话管理直接关系到信号隔离：如果控制终端还在，某次误按Ctrl+C可能会把整个服务组打掉；如果没有终端，网络服务就能完全按自己的节奏处理请求、优雅关闭。这就是为什么几乎每个成熟的网络服务最终都要“守护化”。

5. 手写守护进程：标准五步法，每步都有讲究

5.1 完整的守护化函数

下面这段代码是标准的守护化流程，适用于把任何前台服务变成长期后台服务。认真看注释，每一步都有它的理由：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> void daemonize(void) { pid_t pid; /* 第一次 fork：让父进程退场 */ pid = fork(); if (pid < 0) { exit(1); } if (pid > 0) { exit(0); } /* setsid：创建新会话，成为会话组长和进程组组长 */ if (setsid() < 0) { exit(1); } /* 第二次 fork：确保自己不再是会话组长 */ pid = fork(); if (pid < 0) { exit(1); } if (pid > 0) { exit(0); } /* 处理“继承的遗产” */ umask(0); if (chdir("/") < 0) { exit(1); } int fd = open("/dev/null", O_RDWR); if (fd < 0) { exit(1); } dup2(fd, 0); dup2(fd, 1); dup2(fd, 2); if (fd > 2) { close(fd); } }

配合一个最简单的TCP echo服务，就能看出整条链路是怎么跑通的：

#include <sys/socket.h> #include <netinet/in.h> #include <string.h> int main(void) { daemonize(); int lfd = socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in addr; memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_addr.s_addr = htonl(INADDR_ANY); addr.sin_port = htons(9876); int one = 1; setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one)); bind(lfd, (struct sockaddr *)&addr, sizeof(addr)); listen(lfd, 16); for (;;) { int cfd = accept(lfd, NULL, NULL); if (cfd < 0) { continue; } char buf[1024]; ssize_t n = read(cfd, buf, sizeof(buf)); if (n > 0) { write(cfd, buf, n); } close(cfd); } }

运行编译好的程序后，终端会立刻“卡住”一下，然后返回命令提示符——因为父进程已经退出了。服务在后台继续监听9876端口。即使你退出SSH，再用客户端连上去，它依然活着。

5.2 两次fork各怀心思

第一次fork的目的非常明确：让父进程退出，让调用setsid()的子进程不再是进程组组长。为什么不是进程组组长很重要？因为setsid()有一个硬性限制：调用者如果是进程组组长，调用直接返回EPERM。而fork()出来的子进程继承了父进程的PGID，通常它的PID不等于这个PGID，所以它不是组长，setsid()才有机会成功。

第二次fork就更有讲究了。setsid()之后，子进程已经成为新会话的组长。会话组长有一个特殊能力：如果它后来打开了一个终端设备，而这个终端没有被别的会话占用，内核会让它成为这个终端的新控制终端。这太危险了——守护进程理论上应该永无终端，结果它自己“手滑”打开一个/dev/console，就重新长出了一条电话线。

第二次fork之后，真正干活的进程不再是会话组长。不是会话组长就没有获取控制终端的资格，哪怕它主动去open终端设备也不会被分配控制终端。这才是“双fork”的真正意义：第一次fork是为了setsid()能成功，第二次fork是为了setsid()之后不再保有“获得终端的资格”。

有些人觉得“反正我不会去open终端设备”，于是省掉第二次fork，结果某天第三方库偷偷打开了一个终端设备，整个守护进程就又变成了一个有控制终端的会话。这种bug极其隐蔽。所以我的建议是：别省，五步按部就班走完，一次到位。

5.3 umask、chdir、重定向：处理“继承的遗产”

守护进程是从某个父进程里fork出来的，它不可避免地继承了父进程的一堆环境残留，必须主动清理。

umask(0)是把文件创建权限掩码清零。继承的umask是不可预测的：如果你在某个终端里设置过022甚至077，守护进程创建出来的文件权限就会跟着变，可能该可读的别人读不了。设成0之后，创建什么权限完全由代码里的open()参数决定，你才拥有绝对控制权。当然，安全敏感的守护进程通常会专门设置一个合适的umask值，而不是一味清零，这取决于你的场景。

chdir("/")是为了不占住某个目录。假如你在/home/user/tmp里启动了守护进程，而它不切换目录，那么/home/user/tmp就被一个长期进程“钉住”了，之后想卸载挂载点、想删除某个目录都会失败。切到根目录是最不占位置的选择。

重定向标准描述符到/dev/null，则是切断和终端最后的一丝“藕断丝连”。如果不做这一步，守护进程虽然已经没有控制终端了，但它的fd 0/1/2还指向原来的终端文件，一旦写日志触发了对终端设备的写操作，可能触发SIGTTOU，或者让终端挂着无法正常关闭。把所有标准描述符指向/dev/null，等于明确宣告：我不需要和任何终端通信。

5.4 能不能用现成的daemon()函数

Linux的C库提供了daemon()函数，可以一行搞定守护化。但我自己的经验是，生产代码里很少直接用，原因有两个：

一是不同libc对daemon()的实现存在差异，尤其是有没有做第二次fork，不同平台并不统一。你在这个发行版上验证过的行为，换到另一个环境可能就不一样了。

二是daemon()把关键步骤全封装了，万一中间哪步失败，你根本不知道具体是setsid()失败了，还是chdir()失败了。而自己写五步，每一步的失败都能打日志、给退出码，排错直观得多。

所以我的态度是：理解daemon()是什么，没问题；但真正上线，自己按五步法写一个daemonize()，放工具库里反复用，心里踏实。

6. 不写C也能守护：nohup、setsid、systemd怎么选

6.1 几个工具的“守护能力”并不一样

很多人图省事，直接nohup ./server &完事。这个做法在临时场景下能用，但它和真正的守护进程有本质区别。我把几个常见做法拉了一张对比表：

nohup做的事很单纯：让进程忽略SIGHUP。但它不会创建新会话，进程仍然待在你登录会话里，仍然持有控制终端相关的上下文。正常退出没什么问题，可一旦终端那头出了状况，或者进程后续需要和终端交互，各种边界问题就来了。disown也类似，它只是把作业从shell的作业表里移除，让shell退出时不去主动打扰它，但进程本身并没有脱离会话。

setsid命令则直接调用了setsid()系统调用，创建新会话、脱离控制终端。所以setsid ./server &比nohup更接近“真·守护化”。不过它仍然是手动管理：没有开机自启，没有崩溃自动拉起，没有统一的日志采集。临时调试够用，当成生产方案还是太单薄。

提示：判断一个后台进程是否真的可靠，别只看它当下活着，要看它ps结果里的SID和TTY。TTY是?、SID和原登录会话不同，才算真正独立了。

6.2 systemd单元：从“手写守护”到“交给系统”

现代Linux发行版里，正确的长期服务姿势是写systemd单元文件，而不是自己在程序里做全套守护化。systemd已经把“无人值守长期运行”这件事接管了，你再手工setsid、再双fork，反而是添乱。

systemd用Type=simple要求你的程序以“前台模式”运行。这看起来和守护进程的理念冲突，其实是分工变了：你的程序只需要老老实实待在前台处理业务，后台化、退出保护、日志采集、开机自启，全部由systemd负责。这种模式下，程序不用调daemonize()，代码少了一大截，出错的概率也小得多。

6.3 一份可以直接抄的service文件

下面是一个最小可用的TCP服务单元文件：

[Unit] Description=Demo Network Echo Server After=network-online.target Wants=network-online.target [Service] Type=simple User=demo Group=demo WorkingDirectory=/opt/demo ExecStart=/usr/local/bin/demo-server Restart=always RestartSec=3 StandardOutput=journal StandardError=journal SyslogIdentifier=demo-server [Install] WantedBy=multi-user.target

安装启用：

sudo cp demo-server.service /etc/systemd/system/ sudo systemctl daemon-reload sudo systemctl enable --now demo-server sudo systemctl status demo-server

看日志：

journalctl -u demo-server -f

这套组合拳下来，服务是开机自启的、崩溃会自动拉起、日志统一进journal、权限可以单独限定。比任何手写守护进程都省心。如果某个老程序已经写死了“双fork”逻辑，那就把Type=simple改成Type=forking，再配上PIDFile=告诉systemd主进程PID写在哪，否则systemd会认为启动失败。这一条我在下一节具体展开。

7. 守护进程调试中的四个真坑

7.1 守护进程“没输出”，其实是没地方输出

手写守护进程之后最常见的第一反应是：程序跑起来了，但我的printf去哪了？答案很简单，标准输出已经被重定向到/dev/null了。如果你把dup2(fd, 1)换成指向一个日志文件，那printf还能写到文件里，但谁也不会靠printf管一个长期服务。

正确做法是让服务使用自己的日志设施：要么直接写日志文件，要么用syslog()，要么在systemd环境里直接写STDERR，journal会帮你收。我见过最隐蔽的坑是：程序在守护化之前先open了一个日志文件，把fd记成了全局变量，结果守护化时把所有fd都关掉了，后面一写日志就写到一个已经关闭的fd上，产生各种未定义行为。所以日志初始化一定要放在守护化完成之后。

7.2 重复启动导致端口冲突：PID文件怎么写

手写守护进程还有一个经典问题：服务没做到“单实例”。你跑一次，退出了，再跑一次，新进程起来了，但旧进程可能还占着端口。我建议手写守护进程时做一个单实例检查：

• 启动时尝试绑定端口，如果bind()失败，说明端口被占，直接退出并打日志。
• 或者更规范一点，向/run写一个PID文件，启动前先读PID文件，检查对应进程是否存活。

PID文件本身也有讲究：写入之前用O_CREAT|O_EXCL创建，避免两个进程同时抢着写；进程退出时记得删除文件。不然就会出现“端口已经空出来了，但PID文件里还留着一个旧PID”的误导性信息。调试端口冲突时，先ss -tlnp | grep 9876看看谁占着，再查PID文件，效率会高很多。

7.3 Type=forking和systemd的“假启动失败”

老式程序“双fork”之后父进程退出，这在shell眼里理所当然，但在systemd眼里需要额外交代。如果你配的是Type=simple，systemd觉得你的主进程必须一直活着；而你fork完，原始进程直接exit了，systemd就会认为服务启动失败，立刻执行Restart=always的重启逻辑，然后反复循环。

解决方法是改成Type=forking，同时告诉systemd子进程的PID写在哪个文件里：

[Service] Type=forking PIDFile=/run/demo-server.pid ExecStart=/usr/local/bin/demo-server

程序里在daemonize()完成后写PID文件，退出时清理。这样systemd才能准确跟踪“哪个进程才是这个服务的主体”。如果你要维护的老程序没有PID文件逻辑，那简单粗暴的办法是把它的守护化逻辑去掉，改成前台运行，配合Type=simple，反而省事。

7.4 环境变量、工作目录、umask带来的隐蔽bug

守护进程脱离终端后，最隐蔽的一类坑来自“环境残留的不确定性”。它没有shell，没有那个设置过PATH、HOME的登录环境，所以你在脚本里理所当然依赖的PATH、相对路径、默认umask，在这里全都不靠谱。

我遇到过几次这样的问题：服务的配置文件写的相对路径，比如conf/app.conf，chdir("/")之后根本找不着；日志模块依赖环境变量LOG_LEVEL，结果守护环境下这个变量不存在，日志级别变成默认值，问题被“淹没”了。排查这类问题，最好的办法不是猜，而是用/proc检查进程的实际状态：

cat /proc/$(pgrep demo-server)/environ | tr '\0' '\n' cat /proc/$(pgrep demo-server)/cwd

看看它的环境变量、当前工作目录到底长什么样。写守护进程时，凡是文件路径一律用绝对路径，配置文件、日志路径、PID文件路径全部写死；凡是要用的环境变量，在程序里显式读取并给出默认值；umask也要主动设置。这些细节平时不起眼，但恰恰是“为什么我手动跑没问题，变成守护进程就不行”的常见答案。

写到这里，Linux进程间关系和守护进程这条线基本串清楚了。我的个人体会是：这套机制不需要死记代码，关键是建立一张“组织模型”的图景——进程组是班组，会话是单位，控制终端是单位里那根电话线；守护进程的本质，就是主动切断电话线、脱离原单位、独自长期值守的“独立员工”。而现代Linux环境里，与其在代码里手写双fork，不如优先把服务交给systemd托管，自己只负责把前台逻辑写好。但那些底层的进程关系知识并没有过时——现在容器、嵌入式系统、入门级Linux环境里，手写守护进程依然是基本功。理解透了这套模型，以后再遇到“进程莫名其妙消失”“服务跟着登录会话陪葬”“后台程序突然被信号打断”，你大概一眼就能定位问题出在哪一层。