Linux 开机自启动怎么做：systemd service 文件的最小实用写法

如果你现在还在把服务启动脚本塞进 rc.local，很多时候不是完全不能用，而是已经不够现代也不够可控了。

对现在主流 Linux 发行版来说，真正应该优先掌握的是 systemd。

先说结论

部署长期运行服务时，优先用 systemd 管理，而不是：

• 手工 nohup
• 开机脚本里随便追加命令
• 靠终端会话维持进程

因为 systemd 至少能帮你解决：

• 开机自启动
• 统一启停
• 失败重启
• 日志查看

一、为什么更推荐 systemd

systemd 的好处不只是“能自启动”，而是服务生命周期更可控。

你可以明确声明：

• 启动命令是什么
• 运行用户是谁
• 工作目录在哪
• 失败后要不要重启
• 服务依赖网络还是其他组件

这比随手起一个后台进程靠谱得多。

对个人站点来说，它不一定只用来托管 Java 服务，也很适合管理：

• Node 构建服务
• 自定义脚本
• 定时同步任务
• docker compose 启动项

二、一个最小可用的 service 文件

假设你的 Java 服务放在 /opt/app/demo.jar，可以创建：

/etc/systemd/system/demo.service

[Unit]
Description=demo service
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/app
ExecStart=/usr/bin/java -jar /opt/app/demo.jar
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

这已经足够覆盖大多数单体服务场景。

三、部署后常用的几条命令

重新加载配置

systemctl daemon-reload

启动服务

systemctl start demo

设置开机自启动

systemctl enable demo

查看状态

systemctl status demo

停止服务

systemctl stop demo

重启服务

systemctl restart demo

四、如果当前服务是 Docker Compose，要不要也交给 systemd

很多人会纠结：

• 已经用了 Docker，是不是就完全不需要 systemd 了

不一定。

如果你希望机器重启后自动把整组容器按固定方式拉起来，比较常见的做法就是：

• Compose 管容器编排
• systemd 管 Compose 这条启动命令

也就是说，两者不是替代关系，而是可以配合。

例如：

[Unit]
Description=nginx compose stack
After=docker.service network.target
Requires=docker.service

[Service]
Type=oneshot
WorkingDirectory=/mydata/nginx
ExecStart=/usr/bin/docker compose up -d
ExecStop=/usr/bin/docker compose down
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

这种方式特别适合你现在这种“Docker Nginx + 宿主机挂载目录”的场景。

五、日志怎么看

如果服务起不来，第一反应不要只盯着业务日志，也要直接看 journalctl：

journalctl -u demo -n 100

实时跟日志：

journalctl -u demo -f

这通常能很快看出：

• 路径写错
• 权限不足
• Java 不在预期位置
• 环境变量没生效

六、几个高频配置项

User

指定运行用户。

生产环境里，通常不建议所有服务都用 root 跑。

WorkingDirectory

指定工作目录。

很多相对路径依赖都跟它有关。

Restart

常见可选值：

• no
• on-failure
• always

对大多数后端服务，on-failure 或 always 都比较常见。

Environment

如果服务依赖环境变量，可以直接在 service 文件中写：

Environment=SPRING_PROFILES_ACTIVE=prod

七、rc.local 还能不能用

能用，但不建议把它当主方案。

它的问题主要在于：

• 粒度粗
• 缺少统一状态管理
• 不方便做标准化运维

对于真正长期运行的服务，systemd 会明显更稳。

八、常见排查点

如果服务没有按预期启动，优先看这些：

• ExecStart 路径是否正确
• 运行用户是否有访问目录的权限
• JDK 路径是否存在
• 配置文件、日志目录是否可读写
• 服务是不是改了文件但没执行 daemon-reload

如果管理的是 Compose 服务，再多看两项：

• docker 服务是不是已经先启动
• WorkingDirectory 是不是指到了正确的 compose 文件目录

九、什么时候不一定要用 systemd

如果当前服务本身已经完全交给：

• Kubernetes
• 云厂商托管平台
• 专门的进程管理器

那就不一定要再自己写 systemd。

但只要你现在主要还是在一台 Linux 服务器上长期跑服务，它依然是很值得掌握的基础能力。

一句话总结

systemd 不只是“开机自启动工具”，而是 Linux 服务管理的标准入口。

只要你的服务打算长期跑在服务器上，就值得把 service 文件写规范，这会让后续部署、重启和排障都省很多事。