Java应用作为Systemd服务启动失败主因是未正确配置ExecStart和Type：须用绝对路径调用java、指定-jar及jar绝对路径，设Type=simple、Restart=on-failure，并配WorkingDirectory和User。
Java应用作为Systemd服务启动失败的典型现象
最常见的表现是执行 systemctl start myapp 后立即退出，systemctl status myapp 显示 Active: inactive (dead) 或 failed，日志里出现 Process exited with code 1、no main manifest attribute，或根本没输出——这通常不是Java没装好，而是Systemd没被正确“说服”：它默认把Java进程当一次性命令，启动完就收尾，不等JVM真正跑起来。
写对 ExecStart 才能留住JVM进程
关键在于让Systemd识别Java是长期运行的服务，而不是执行完就结束的脚本。必须用完整路径调用 java，并显式指定 -jar 和绝对路径的jar包，不能依赖当前工作目录或shell环境变量。
-
ExecStart=/usr/bin/java -Xms256m -Xmx512m -jar /opt/myapp/app.jar✅（推荐） -
ExecStart=java -jar app.jar❌（找不到java、找不到jar、没-X参数易OOM） -
ExecStart=/bin/sh -c 'cd /opt/myapp && java -jar app.jar'❌（shell退出后JVM被杀）
如果jar包依赖外部配置文件，务必用 WorkingDirectory 指定路径，而非在 ExecStart 里用 cd；否则Systemd无法正确追踪主进程。
必须设置 Type=simple 并配好 Restart 策略
Java应用启动后JVM即成为主进程，所以 Type 必须是 simple（默认值），不能设成 forking（那是为传统daemon设计的，会误判Java的PID）。
立即学习“Java免费学习笔记（深入）”；
-
Type=simple（显式声明更安全，避免继承默认值歧义） -
Restart=always或Restart=on-failure（否则崩溃后不会自动拉起） -
RestartSec=5（避免频繁重启打满日志） -
User=myapp（强烈建议用独立非root用户运行，避免权限泄露）
漏掉 Restart 是生产环境最常踩的坑：应用OOM或未捕获异常退出后，服务就静默挂了，监控都收不到告警。
验证和调试时盯紧 journalctl 和进程树
别只看 systemctl status 的一句话状态。真实问题藏在日志里：
-
journalctl -u myapp -f实时看启动输出（尤其注意classpath、配置文件路径、端口占用报错） -
ps aux | grep java确认进程是否真在跑，且UID符合User=设置 -
systemctl cat myapp检查unit文件是否被覆盖或加载的是旧版本（修改后必须systemctl daemon-reload）
一个容易被忽略的细节：如果jar包用 spring-boot-maven-plugin 打包，确保 MANIFEST.MF 里有 Main-Class: org.springframework.boot.loader.JarLauncher，否则 java -jar 会报 no main manifest attribute——这不是Systemd的问题，但会卡在第一步。
