以下是针对springboot 1.3及以上版本的工作:

init。d服务

可执行jar具有通常的启动、停止、重新启动和状态命令。它还将在通常的/var/run目录中设置一个PID文件，默认情况下在通常的/var/log目录中设置日志。

你只需要将你的jar文件符号链接到/etc/init.D喜欢这样

sudo link -s /var/myapp/myapp.jar /etc/init.d/myapp

OR

sudo ln -s ~/myproject/build/libs/myapp-1.0.jar /etc/init.d/myapp_servicename

之后你就可以做平常的事情了

/etc/init.d/myapp start

然后在你想启动/停止应用程序的运行级别设置一个链接。

作为一个systemd服务

要运行安装在var/myapp中的Spring Boot应用程序，可以在/etc/systemd/system/myapp.service中添加以下脚本:

[Unit]
Description=myapp
After=syslog.target

[Service]
ExecStart=/var/myapp/myapp.jar

[Install]
WantedBy=multi-user.target

注意:如果你正在使用这种方法，不要忘记让jar文件本身可执行(使用chmod +x)，否则它将失败，错误“权限被拒绝”。

参考

http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/html/deployment-install.html#deployment-service

我知道这是一个老问题，但我想提出另一种方法，即appassembler-maven-plugin。以下是我POM中的相关部分，其中包括许多我们认为有用的额外选项值:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>appassembler-maven-plugin</artifactId>
    <configuration>
        <generateRepository>true</generateRepository>
        <repositoryLayout>flat</repositoryLayout>
        <useWildcardClassPath>true</useWildcardClassPath>
        <includeConfigurationDirectoryInClasspath>true</includeConfigurationDirectoryInClasspath>
        <configurationDirectory>config</configurationDirectory>
        <target>${project.build.directory}</target>
        <daemons>
            <daemon>
                <id>${installer-target}</id>
                <mainClass>${mainClass}</mainClass>
                <commandLineArguments>
                    <commandLineArgument>--spring.profiles.active=dev</commandLineArgument>
                    <commandLineArgument>--logging.config=${rpmInstallLocation}/config/${installer-target}-logback.xml</commandLineArgument>
                </commandLineArguments>
                <platforms>
                    <platform>jsw</platform>
                </platforms>
                <generatorConfigurations>
                    <generatorConfiguration>
                        <generator>jsw</generator>
                        <includes>
                            <include>linux-x86-64</include>
                        </includes>
                        <configuration>
                            <property>
                                <name>wrapper.logfile</name>
                                <value>logs/${installer-target}-wrapper.log</value>
                            </property>
                            <property>
                                <name>wrapper.logfile.maxsize</name>
                                <value>5m</value>
                            </property>
                            <property>
                                <name>run.as.user.envvar</name>
                                <value>${serviceUser}</value>
                            </property>
                            <property>
                                <name>wrapper.on_exit.default</name>
                                <value>RESTART</value>
                            </property>
                        </configuration>
                    </generatorConfiguration>
                </generatorConfigurations>
                <jvmSettings>
                    <initialMemorySize>256M</initialMemorySize>
                    <maxMemorySize>1024M</maxMemorySize>
                    <extraArguments>
                        <extraArgument>-server</extraArgument>
                    </extraArguments>
                </jvmSettings>
            </daemon>
        </daemons>
    </configuration>
    <executions>
        <execution>
            <id>generate-jsw-scripts</id>
            <phase>package</phase>
            <goals>
                <goal>generate-daemons</goal>
            </goals>
        </execution>
    </executions>
</plugin>

I don't know of a "standard" shrink-wrapped way to do that with a Java app, but it's definitely a good idea (you want to benefit from the keep-alive and monitoring capabilities of the operating system if they are there). It's on the roadmap to provide something from the Spring Boot tool support (maven and gradle), but for now you are probably going to have to roll your own. The best solution I know of right now is Foreman, which has a declarative approach and one line commands for packaging init scripts for various standard OS formats (monit, sys V, upstart etc.). There is also evidence of people having set stuff up with gradle (e.g. here).

我试图使springboot应用程序呈现为“init”。D”风格的shell脚本与压缩Java应用程序钉在最后

通过符号链接这些脚本从/etc/init.D /spring-app到/opt/spring-app.jar，并chmod jar使其可执行。D /spring-app启动/etc/init。D /spring-app stop”和其他可能的状态工作

假设是init。来自springboot的d风格脚本看起来他们有必要的魔法字符串(像# Default-Start: 2 3 4 5) chkconfig将能够将其作为“服务”添加。

但是我想让它和systemd一起工作

为了做到这一点，我尝试了上面其他答案中的许多食谱，但在Centos 7.2和Springboot 1.3上，它们都不适合我。大多数情况下，它们会启动服务，但无法跟踪pid

最后，我发现下面的方法对我有用，当/etc/init.D链接也到位了。一个类似于下面的文件应该安装为/usr/lib/systemd/system/spring-app.service

[Unit]
Description=My loverly application
After=syslog.target 

[Service]
Type=forking
PIDFile=/var/run/spring-app/spring-app.pid
ExecStart=/etc/init.d/spring-app start
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

在systemd单元文件中，您可以通过目录或EnvironmentFile设置环境变量。我建议这样做，因为这似乎是最小的摩擦。

示例单元文件

$ cat /etc/systemd/system/hello-world.service
[Unit]
Description=Hello World Service
After=systend-user-sessions.service

[Service]
EnvironmentFile=/etc/sysconfig/hello-world
Type=simple
ExecStart=/usr/bin/java ... hello-world.jar

然后在/etc/sysconfig/hello-world下设置一个文件，其中包含Spring Boot变量的大写名称。例如，一个名为server的变量。port将遵循SERVER_PORT形式作为环境变量:

$ cat /etc/sysconfig/hello-world
SERVER_PORT=8081

这里所利用的机制是Spring Boot应用程序将获取属性列表，然后转换它们，将所有内容都改为大写，并将点替换为下划线。一旦Spring Boot应用程序完成了这个过程，它就会寻找匹配的环境变量，并相应地使用找到的环境变量。

在这篇题为:如何通过环境变量在其名称中设置带有下划线的Spring Boot属性的SO Q&A中强调了更多细节?

参考文献

第四部分。弹簧引导功能- 24。外部化配置

对于SpringBoot 2.4.4，除了由 @ismael

我在maven pom.xml中有以下内容，使其成为可执行jar

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>               
            <configuration>
                <executable>true</executable>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>repackage</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>