前言
Linux服务器有时候会因为服务重启等原因，导致服务器上面的应用不可用。针对这种场景，本文会介绍三种常见的方法来进行解决，希望对各位读者有所帮助。
- 环境说明：Linux Red Hat 7.4
一、通过rc.local文件来实现
rc.local文件位于/etc/rc.d目录下，当Linux系统开机时会以root权限对这个文件中的脚本内容进行执行，所以我们可以通过在这个文件中加入应用启动脚本来完成我们想要的效果。
步骤一：编辑/etc/rc.d/rc.local文件
nohup java -jar /opt/application.jar &
这里需要注意，在shell执行命令后加 & 是为了让应用程序在后台运行，rc.local也是一个脚本，主进程在运行这个脚本时必须能够返回，如果在这个脚本里面执行了一些死循环或者其他无法返回的任务，整个系统就很可能卡死在这里，无法启动，所以在这里运行的用户程序必须是能够返回或者本身就使用一些后台运行的进程。
更推荐的书写方式是，不直接将命令写在rc.local文件中，我们可以单独写一个启动脚本出来，rc.local脚本只需要单独后台执行一下这个脚本即可（如果脚本确认不会阻塞进程的话，那么不加&也关系不大）。
sh /opt/auto_start.sh
步骤二：rc.local文件授权
chmod +x /etc/rc.d/rc.local
步骤三：重启服务器进行验证
reboot
小拓展1：脚本的执行流程
1、运行
级别脚本：初始化系统会根据配置的运行级别（Runlevel）执行相应的启动脚本。这些脚本位于 /etc/rc.d/ 目录或类似的位置，并根据运行级别的定义执行相应的初始化操作。
2、/etc/rc.d/rc.sysinit：这是一个用于系统初始化的脚本文件，通常是在运行级别脚本执行之后、在启动过程的早期阶段执行的。它负责执行一些基本的系统设置、设备初始化、加载内核模块以及其他必要的准备工作。
3、/etc/rc.d/rc脚本：这是一个控制系统引导过程的主要脚本，它根据运行级别和其他配置执行不同的操作。该脚本会依次执行各个运行级别脚本，并在适当的时候加载服务、启动守护进程等。
4、/etc/rc.d/rc.local：在上述步骤完成后，初始化系统会执行 /etc/rc.d/rc.local 脚本。它是在引导过程的最后阶段执行的，用于运行用户自定义的命令或脚本。
小拓展2：指定脚本的执行用户
由于rc.local是以root用户来执行脚本的，但实际上我们生产环境中一般是使用应用账户来进行服务管理，如果我们希望用指定用户来启动脚本，可以通过以下方式来实现。
su -c "/opt/reboot-application.sh" -s /bin/bash aa
- -c参数表示指定用户执行，用户名加在最后
- -s /bin/bash 参数表示使用bash命令来解释脚本
注意事项：
①相关的启动文件记得先赋权
②rc.local文件的启动在系统完成环境变量完全初始化之前，所以可能会出现部分环境变量未初始化导致的脚本启动失败问题，想要解决这个问题，可以通过在脚本中手动export环境变量来实现。
rc.local is a file, owned by root.root and should be mode 755. The rc.local file is for initialization of programs after the system has fully booted. This script is run right before login prompts are displayed. You can use the file to run last minute startups, set certain environment variables, etc.
Conversely, if you want to start something before everything else, you would use the regular file in /etc/rc.d called rc.sysinit, which should have the same owner and permissions.
二、使用crontab来实现
crontab是linux自带的定时器，且支持每个用户单独配置自己的定时器，我们可以利用定时器的特性来完成服务的检查和重启。
步骤一：切换应用账户（如果没区分应用账户的话，也可以直接用root）
# 切换到应用账户
su - test
# 编辑当前应用账户的定时任务列表
crontab -e
# 新增一条定时任务，每隔1分钟执行一次脚本
*/1 * * * * sh /opt/uShell/reboot-application-crontab.sh >>/opt/uShell/reboot-application-crontab.log 2>&1
注意事项
（1）由于crontab任务会一直执行，所以我们的脚本除了启动服务的内容外，还需要在前面检查服务当前是否启动，若启动则不进行任何处理，避免出现重复启动服务的问题。
（2）crontab对于脚本的执行同样会有环境变量缺失的问题，解决这个问题可以有2种方式：① 手动在脚本中指定一下所需的环境变量 ② 在脚本文件中执行source /etc/profile和source ~/.bash_profile来手动初始化登录用户的环境变量
三、使用 service 服务来实现
systemctl是Linux中systemd工具中的一个核心组件，可以用于管理系统服务和进程。它提供了一种统一的方式来启动、停止、重启和查看系统服务的状态。而Service服务就是systemctl所管理的最小单位，我们可以通过编写自定义的Service服务来简化我们运维的成本。以下是常见的操作命令：
# 启动一个服务
sudo systemctl start servicename.service
# 重启一个服务
sudo systemctl restart servicename.service
# 停止一个服务
sudo systemctl stop servicename.service
# 设置一个服务开机自启动
sudo systemctl enable servicename.service
# 关闭一个服务的开机自启动
sudo systemctl disable servicename.service
# 查看所有服务的状态
sudo systemctl list-units --type=service
下面我们来简单写一个Service服务
步骤一：编写service脚本
脚本需要存放在/etc/systemd/system下面，对应的文件名为xxxxx.service，文件名可以自己定义但是要保证后缀为.service
[Unit]
Description=Manage My Application
After=network.target
[Service]
Type=forking
ExecStart=/opt/uShell/reboot-application-service.sh
User=test
[Install]
WantedBy=multi-user.target
这里做一个简单的解释
-
Unit 这个模块下面一般用来写service的通用信息
Description 描述Service的作用
After 表示在这些文件启动后才能够启动 -
Service 定义服务本体
Type #服务的类型，值为forking时，systemd 会监控主进程和子进程的状态，并认为服务进程在主进程退出后会继续运行。通常，服务进程会在启动后立即分叉出一个子进程，而主进程会退出。
ExecStart #这个参数是几乎每个 .service 文件都会有的，指定服务启动的主要命令，在每个配置文件中只能使用一次。
ExecStop #停止服务所需要执行的主要命令 -
Install
RequiredBy 单元被允许运行需要的一系列依赖单元，RequiredBy列表从Require获得依赖信息。
WantBy 单元被允许运行需要的弱依赖性单元，Wantby从Want列表获得依赖信息。
注意事项：
（1）其实[Install]和[Unit]中的Before和After效果有些类似，都是可以用来指定服务的启动顺序，只是对于依赖关系我们用[Install]的字段来解决会更加合适一些。
（2）和crontab有点类似的是，service服务可以指定执行的用户（还能指定用户组），这点是相对比较友好的
（3）还是有环境变量的问题，需要在脚本里面手动做环境变量初始化，或者在服务里面指定一下初始化变量的脚本
步骤二：对脚本进行赋权和启动
# 赋权
chmod 755 /opt/systemd/system/reboot-application.service
# 设置开机自启动，这里的服务名就是 .service 前面的名称
systemctl enable reboot-application
# 启动服务
systemctl start reboot-application
# 我们可以看到服务当前的状态
systemctl status reboot-application
如果服务的状态为"failed"，可以使用sudo journalctl -xe命令来查看日志以获取更多信息
如果在启动服务时出现问题，可以使用sudo systemctl daemon-reload命令重新加载systemd配置文件
小结
文章介绍的三种方法都可以用来实现服务器重启后应用恢复的效果，但个人觉得crontab更适合用来做定时处理的任务，用于做重启脚本不是最佳选择（当然了，做肯定是可以做的），因为crontab做服务恢复的原理是定时扫描服务是否处于alive状态，若扫描间隔的时间太长则实时性无法得到保障，若扫描间隔时间太短，则浪费系统资源。（当然了，只是看应用存活状态也花不了太多资源）。
较好的选择还是使用systemctl或者/etc/rc.d/rc.local文件来实现，前者胜在综合能力强，后续可以拓展成服务管理模块来运维，后者胜在方便，选择哪一个方案可以根据项目实际情况来决定。
网友评论