利用systemd设置springboot微服务服务在linux重启后自启动

要使 Spring Boot 服务的 JAR 包在 Linux 重启后自启动，您可以使用 systemd。以下是步骤：

1. 创建一个 systemd 服务单元文件

在 /etc/systemd/system/ 目录下，创建一个新的服务单元文件，例如 my-springboot-app.service。使用 sudo 打开一个文本编辑器来创建和编辑文件：

sudo nano /etc/systemd/system/my-springboot-app.service

然后，向文件中添加以下内容：

[Unit]
Description=My Spring Boot App
After=syslog.target

[Service]
User=your_username
ExecStart=/usr/bin/java -jar /path/to/your/springboot/app.jar
SuccessExitStatus=143
TimeoutStopSec=10
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

• User：运行此服务的用户的名称。
• ExecStart：启动 Spring Boot 服务的命令。确保将 /path/to/your/springboot/ 替换为您的 JAR 文件的实际路径。
• SuccessExitStatus：Spring Boot 使用 143 作为退出代码，这表明应用程序已成功关闭。

保存并关闭文件。

2. 重新加载 systemd 以识别新服务

sudo systemctl daemon-reload

3. 启动您的服务

sudo systemctl start my-springboot-app.service

4. 启用服务以在启动时自动开始

sudo systemctl enable my-springboot-app.service

现在，每次系统启动时，您的 Spring Boot 应用程序都将自动启动。

请注意，为了使上述设置工作，确保您的 Spring Boot JAR 包具有适当的文件权限，并且在指定的路径上可以访问。此外，如果您的应用程序需要其他环境变量或系统属性，确保在 ExecStart 中设置它们。

配置使用脚本启动jar包服务

如果您有一个名为 app.sh 的启动脚本，并且使用 sh ./app.sh start 来启动 app.jar，那么您可以在 systemd 服务单元文件中直接引用此脚本来启动服务。

修改 /etc/systemd/system/my-springboot-app.service 文件中的 ExecStart 行如下：

ExecStart=/bin/sh /path/to/your/app.sh start

确保将 /path/to/your/ 替换为您的脚本文件的实际路径。

请注意，为了使这种设置工作，您的 app.sh 脚本必须具有可执行权限。您可以使用以下命令为脚本设置可执行权限：

chmod +x /path/to/your/app.sh

此外，如果您的脚本需要在特定的工作目录中运行，您还可以在 systemd 服务单元文件中设置 WorkingDirectory，例如：

WorkingDirectory=/path/to/your/

这将确保当服务启动时，它的当前工作目录被设置为脚本所在的目录。

 

“After=syslog.target”什么意思？

在 systemd 服务单元文件中，After 指令定义了启动顺序依赖关系。After=syslog.target 指定了在启动当前服务之前，首先要启动或激活 syslog.target。这确保了在当前服务启动之前，系统日志机制已经处于活动状态，从而允许当前服务向日志发送任何消息。

让我们深入了解其中的一些关键部分：

1. syslog.target: 这是一个目标，类似于旧的 SysV init runlevels。在 systemd 中，目标用于组织和管理一组相关的服务和其他单元。

2. After: 这是一个排序依赖关系。它告诉 systemd 在启动当前服务之前要确保列出的其他单元/服务/目标已经启动。这并不意味着 syslog.target 必须被激活，但如果它被激活了，那么当前服务将在它之后启动。

对于 After=syslog.target，这意味着如果系统日志守护程序（如 rsyslog 或其他任何兼容的日志守护程序）已经启动或被触发启动，那么当前服务将在其之后启动。

为了确保有序的启动和稳定的运行环境，定义这种依赖关系是很有用的。在上述情况中，这确保了在当前服务产生任何日志之前，日志机制已经准备就绪。