systemd守护Java进程中，脚本后续任务执行失败的解决方法

这个问题的核心原因是systemd默认会管理整个控制组（cgroup）的进程：当作为守护进程的Java主进程被终止时，systemd会默认终止该控制组下的所有关联进程——包括正在运行的脚本，所以job2还没来得及执行就被干掉了。之前的nohup没用，是因为它只能忽略SIGHUP信号，但systemd发送的是SIGTERM或者直接通过cgroup回收进程，nohup挡不住这种情况。

下面给你几个可行的解决方案，按从易到难排序：

方案1：修改systemd服务配置（最推荐） #

直接调整你的systemd .service文件，告诉它只杀死主进程，不要牵连其他子进程：

[Service]
# 其他配置保持不变
KillMode=process  # 默认是control-group，改成process后只杀主进程

重启systemd服务后再测试：

sudo systemctl daemon-reload
sudo systemctl restart your-java-service.service

这个方案最简单，不需要修改Java代码或脚本逻辑，直接从systemd层面解决问题。

方案2：让脚本脱离Java的进程组 #

如果不能修改systemd配置，可以在Java启动脚本时，用setsid命令让脚本在独立的会话/进程组中运行，这样即使Java进程被杀死，脚本也不会被牵连：
修改Java中的启动代码，把脚本启动命令改成：

ProcessBuilder pb = new ProcessBuilder("setsid", "/path/to/your-script.sh");
pb.directory(new File("/your/script/dir"));
// 可选：重定向输出避免阻塞
pb.redirectOutput(new File("/var/log/script-out.log"));
pb.redirectError(new File("/var/log/script-err.log"));
pb.start();

setsid会创建一个新的会话和进程组，脚本会成为这个新组的leader，和Java进程的进程组彻底脱离，杀死Java时不会影响到它。

方案3：调整脚本逻辑，让job2独立运行 #

如果上面两个方案都不行，可以修改你的脚本，把job2放到独立的后台会话中执行，再杀死Java进程：

#!/bin/bash

# 先执行job1
echo "Running job1..."
./job1.sh

# 将job2放到独立的子shell中，用nohup+&让它脱离当前会话
echo "Starting job2 in background..."
(nohup ./job2.sh > /var/log/job2-out.log 2>&1 &)

# 现在杀死Java进程
echo "Killing Java process..."
kill $JAVA_PID

这里的括号()会创建一个子shell，nohup让job2忽略挂起信号，&让它后台运行，这样即使当前脚本被终止，job2的子进程也能继续执行。

为什么之前的nohup没用？ #

nohup的作用只是让进程忽略SIGHUP（终端挂起）信号，但在systemd场景下，杀死Java后，systemd是通过cgroup或者进程组发送SIGTERM信号终止所有关联进程，nohup对这种信号无效，必须让目标进程脱离systemd的控制组或者Java的进程组才行。

内容的提问来源于stack exchange，提问作者ihsan çiftci