一、问题背景：麒麟OS上nohup后台任务的坑
不少在麒麟OS做开发或运维的朋友都碰到过这个问题：明明用了nohup启动后台任务，还加了&符号，结果登出终端或者终端断开连接后，任务直接被挂断，甚至有时候连终端没断，任务自己就没了。
先给大家说清楚nohup为啥不好用。nohup的核心作用是忽略SIGHUP信号，这个信号是终端断开时发给所有子进程的，正常进程收到这个信号就会退出。但nohup有个致命缺陷：它启动的进程还是会和原来的终端绑定——如果终端被关闭（比如你关了SSH连接），内核会把这个终端对应的进程组全杀掉，哪怕进程忽略SIGHUP也没用。而且nohup没法做自动重启，任务崩了只能手动起，也没法限制资源，要是任务占满CPU或内存，整个服务器都得卡。
所以我们得换更靠谱的方案：用systemd做守护进程，用setsid彻底脱离终端，同时加资源限制和自动重启。
二、核心技术选型解析
2.1 systemd：麒麟OS的原生服务管理器
麒麟OS（尤其是V10及以上版本）默认用的是systemd，这是现在主流Linux发行版的标准服务管理工具。它能把我们的任务注册成一个系统服务，完全脱离终端运行，不管终端断不断都不影响，还能自动监控任务状态、出问题就重启。
2.2 setsid：彻底脱离终端的工具
setsid的作用是让进程开启一个新的会话（session），和原来的终端彻底脱离关系。这样哪怕原来的终端被关闭，这个新会话里的进程也不会收到任何终端相关的信号，完全独立运行。
2.3 资源限制：避免任务拖垮服务器
我们可以通过systemd的配置，限制任务能占用的CPU核心数、内存大小，防止单个任务把服务器资源占满，影响其他服务。
三、完整实现步骤
3.1 技术栈说明
本示例统一使用的技术栈为：麒麟OS V10、systemd、setsid、Shell脚本。
3.2 编写业务测试脚本
先写一个简单的业务脚本，用来模拟我们需要后台运行的任务。这个脚本会每秒输出一次当前时间到日志文件，同时我们可以故意让它偶尔崩溃，用来测试自动重启功能。
#!/bin/bash
# 业务脚本：test_task.sh，模拟需要后台运行的任务
# 日志文件路径
LOG_FILE="/var/log/test_task.log"
# 计数器，用来模拟偶尔崩溃
count=0
# 确保日志文件存在
touch $LOG_FILE
while true; do
# 输出当前时间到日志
echo "$(date +"%Y-%m-%d %H:%M:%S") - 任务正常运行" >> $LOG_FILE
# 计数器加1
count=$((count + 1))
# 每运行10次，故意退出（模拟任务崩溃）
if [ $count -eq 10 ]; then
echo "$(date +"%Y-%m-%d %H:%M:%S") - 任务崩溃" >> $LOG_FILE
exit 1 # 非0退出码表示异常退出
fi
# 每秒运行一次
sleep 1
done
写完之后，给脚本加执行权限：
chmod +x /root/test_task.sh
3.3 编写systemd服务配置文件
systemd的服务配置文件存放在/etc/systemd/system/目录下，我们新建一个叫test-task.service的配置文件，内容如下：
[Unit]
Description=测试后台任务服务 # 服务的描述，随便写
After=network.target # 依赖网络服务，网络起来后再启动这个服务
[Service]
# 运行这个服务的用户，这里用root，也可以改成普通用户
User=root
# 启动命令：用setsid启动我们的业务脚本
ExecStart=/usr/bin/setsid /root/test_task.sh
# 自动重启配置：只要服务不是正常退出（比如崩溃、被kill），就自动重启
Restart=always
# 重启延迟：服务崩溃后，等待1秒再重启，避免频繁重启
RestartSec=1
# 资源限制：限制CPU使用率为1个核心（100%对应1个核心）
CPUQuota=100%
# 资源限制：限制内存最大使用100M，超过就会被OOM killer杀掉，触发自动重启
MemoryLimit=100M
# 日志配置：把服务的标准输出和标准错误都重定向到日志文件，方便排查问题
StandardOutput=append:/var/log/test_task.log
StandardError=append:/var/log/test_task.log
[Install]
# 服务开机自启动的级别，这里是多用户模式，开机就自启动
WantedBy=multi-user.target
3.4 加载并启动服务
配置完之后，需要让systemd重新加载配置，然后启动服务，最后设置开机自启动：
# 重新加载systemd配置，让新的服务配置生效
systemctl daemon-reload
# 启动服务
systemctl start test-task.service
# 设置开机自启动
systemctl enable test-task.service
3.5 验证功能
我们可以用几个命令来验证服务是否正常工作：
- 查看服务状态：
systemctl status test-task.service
正常会显示服务是active (running)状态，还能看到服务已经运行了多久。
- 查看日志：
cat /var/log/test_task.log
能看到每隔1秒输出一次正常运行，每10次输出一次崩溃，然后很快又重启，继续输出正常运行。
- 测试终端断开的影响：现在你关闭当前的SSH终端，重新登录服务器，再看服务状态，会发现服务还在正常运行，完全不受终端断开的影响。
四、应用场景分析
这个方案适合所有需要在麒麟OS上长期后台运行的任务，比如：
- 服务器上的定时采集程序、监控程序；
- 后台运行的服务进程，比如自己开发的中间件、代理服务；
- 长时间运行的计算任务，比如数据处理、模型训练；
- 对稳定性要求高的任务，不能因为终端断开就停止，也不能因为偶尔崩溃就中断。
五、技术优缺点与注意事项
5.1 优缺点分析
优点：
- 彻底脱离终端：不管终端是否断开，服务都能正常运行，解决了nohup的核心问题；
- 自动重启：任务崩溃后会自动重启，大大提高了任务的稳定性；
- 资源限制：可以有效防止单个任务占用过多服务器资源，影响其他服务；
- 原生支持：麒麟OS原生支持systemd，不需要额外安装软件，兼容性好；
- 管理方便：可以用systemctl命令统一管理服务，比如启动、停止、重启、查看状态，操作简单。
缺点：
- 配置稍微复杂：相比nohup一行命令，systemd需要写配置文件，对新手来说有一定门槛；
- 灵活性稍差：如果是临时运行一次的任务，用systemd配置有点麻烦，适合长期运行的任务。
5.2 注意事项
- 权限问题：如果用普通用户运行服务，需要确保业务脚本和日志文件的权限正确，普通用户要有执行脚本和读写日志的权限；
- 资源限制的合理设置：CPUQuota和MemoryLimit要根据服务器的实际情况和任务的需求来设置，不能设得太小导致任务无法正常运行，也不能设得太大失去限制的意义；
- 重启策略的调整：如果任务是因为配置错误导致的频繁崩溃，Restart=always会导致服务不断重启，这时候需要修改业务脚本或配置，而不是依赖自动重启；
- 日志管理：日志文件会不断增大，需要定期清理或者配置日志轮转，避免占满磁盘空间；
- 麒麟OS版本兼容性：这个方案适合麒麟OS V10及以上版本，V7及以下版本可能不支持systemd，需要调整方案。
六、文章总结
在麒麟OS上，nohup因为无法彻底脱离终端，不适合用来启动需要长期后台运行的任务。改用systemd加setsid的方案，可以完美解决终端断开导致任务挂断的问题，同时实现自动重启和资源限制，大大提高任务的稳定性和服务器的安全性。
这个方案的核心是把任务注册成系统服务，完全由systemd来管理，不管是终端断开还是任务崩溃，都能保证任务持续运行，同时通过资源限制避免任务影响整个服务器。对于需要在麒麟OS上运行长期后台任务的开发者和运维人员来说，这是一个非常实用的方案。
评论
围绕“用nohup在麒麟OS上启动后台任务总被挂断，改用systemd和setsid编写守护脚本并限制资源占用与自动重启”参与讨论