systemd启动失败主因是环境变量、工作目录、权限或Java路径不一致；因其不继承shell环境，需显式配置JAVA_HOME、PATH、WorkingDirectory等，否则出现java未找到、版本错配或路径错误。
直接结论：systemd 启动失败，90% 是因为环境变量、工作目录、权限或 Java 路径不一致导致的，不是 Java 本身有问题。
为什么终端能跑，systemd 就报错？
systemd 启动的服务不继承你的 shell 环境 —— JAVA_HOME、PATH、LD_LIBRARY_PATH 全都不生效；它用的是干净的 minimal 环境（类似 root 用户登录前的状态）。你手动执行 java -jar app.jar 时，shell 已经帮你加载了 /etc/profile 或 ~/.bashrc，而 systemd 完全绕过这些。
常见表现包括：
-
java: command not found（PATH缺失） -
UnsupportedClassVersionError（实际用了错误 JDK 版本，比如系统默认是 OpenJDK 11，但项目需要 17） -
No such file or directory（jar 路径写相对路径，WorkingDirectory没设或设错） -
Permission denied（jar 文件或父目录权限不对，systemd 默认以指定用户运行，不等于你当前用户）
必须查的三个日志位置
别猜，先看输出。按优先级顺序执行：
-
systemctl status myapp.service—— 看最后一行“Process: XXXX ExecStart=...”和“Main PID”是否出现，有没有明确 exit code -
journalctl -u myapp.service -n 50 --no-pager—— 查 systemd 捕获的标准输出/错误，常含ClassNotFoundException、Could not find or load main class等关键线索 -
tail -n 30 /var/log/syslog | grep myapp或journalctl -xeu myapp.service—— 补充上下文，尤其当启动卡在“activating”状态时
如果 journalctl 里只有空行或 “Started …” 但没后续，说明进程启动后立刻退出，大概率是 JVM 启动参数或 jar 路径问题。
service 文件里最容易漏掉的配置项
一个可靠的基础配置至少要显式声明以下几项，不能依赖“应该有”：
-
Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64"—— 必须填绝对路径，用update-java-alternatives -l或ls /usr/lib/jvm/确认真实路径 -
Environment="PATH=/usr/local/bin:/usr/bin:/bin:${JAVA_HOME}/bin"—— 显式补全PATH，避免java命令找不到 -
WorkingDirectory=/opt/myapp—— 所有相对路径（如配置文件、日志目录）都基于此；不设则默认为/，极大概率出错 -
User=appuser和Group=appgroup—— 确保该用户对 jar、配置、日志目录有读/执行/写权限（chown -R appuser:appgroup /opt/myapp） -
ExecStart=${JAVA_HOME}/bin/java -Xms512m -Xmx1g -jar /opt/myapp/app.jar—— 不要用java，必须用完整路径；jar 路径也必须绝对
Java 版本错配怎么快速验证？
Spring Boot 3.x 用 Java 8 肯定失败，Neo4j 5.x 用 Java 11 会启动就退出 —— 这类问题不会报“版本不匹配”，而是静默失败或抛出 UnsupportedClassVersionError。
验证方式很简单：
- 在 service 文件中加一行：
ExecStartPre=/bin/bash -c '${JAVA_HOME}/bin/java -version'，然后systemctl daemon-reload && systemctl start myapp，再看 journalctl 输出的 java 版本是否符合预期 - 或者临时把
ExecStart改成：ExecStart=${JAVA_HOME}/bin/java -verbose:class -jar /opt/myapp/app.jar | head -20，观察加载的第一个类是否报 version error
特别注意：Ubuntu 上 openjdk-17-jdk 安装后，真实路径可能是 /usr/lib/jvm/java-17-openjdk-amd64（amd64）或 ...-arm64（ARM），名称不统一，不能只靠包名推断。
真正麻烦的点往往不在 Java 本身，而在 systemd 的“干净环境”和你习惯的交互式 shell 之间的鸿沟。每次改完 service 文件，记得 systemctl daemon-reload，否则修改完全不生效 —— 这个步骤被跳过频率极高。
