Bash脚本如何检测Solr状态 仅在服务未激活时执行重启

你描述的伪代码可以直接通过Bash语法实现，不过更推荐使用systemd原生状态查询接口，比匹配service命令的输出文本更稳定，不会因为不同版本的输出格式变化导致判断失效。

匹配"dead"关键字的基础写法 #

完全对应你给出的伪代码逻辑：

#!/bin/bash
# 捕获solr服务状态输出
solr_status=$(service solr status)
# 判断输出中是否包含dead关键字
if [[ $solr_status == *"dead"* ]]; then
    systemctl stop solr
    # 预留时间让进程完全退出，避免端口、文件锁残留导致启动失败
    sleep 3
    systemctl start solr
fi

更稳妥的生产可用写法 #

不需要解析文本输出，直接调用systemd内置的状态判断命令，systemctl is-active --quiet 服务名会在服务正常运行时返回0退出码，服务异常/停止时返回非0退出码，兼容性更强：

#!/bin/bash
LOG_FILE="/var/log/solr_monitor.log"
# 判断solr是否处于非激活状态
if ! systemctl is-active --quiet solr; then
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Solr is inactive, starting restart flow" >> "$LOG_FILE"
    systemctl stop solr
    sleep 2
    systemctl start solr
    # 重启后二次校验状态，记录失败日志方便排查
    if ! systemctl is-active --quiet solr; then
        echo "[$(date '+%Y-%m-%d %H:%M:%S')] Solr restart failed, please check service manually" >> "$LOG_FILE"
    fi
fi

注意：脚本需要先执行chmod +x restartsolr.sh添加可执行权限，配置cron任务时请写全所有命令和脚本的绝对路径，cron默认的PATH环境变量不全，很容易出现找不到命令的问题。

• 这个方案是可行的轻量自愈方案，在测试环境、非核心小规模业务场景下完全够用，实现成本极低，能解决最常见的服务意外挂掉没人发现的问题。
• 但它不属于生产级最佳实践，存在几个明显缺陷：
  • 故障覆盖范围窄：只能识别服务进程完全退出的场景，对于进程还在但端口无响应、查询接口报错、索引写入阻塞这类"活而不健康"的故障完全无法识别。
  • 恢复延迟高：依赖cron轮询，如果你配置5分钟执行一次，服务挂掉之后最多要等5分钟才能被拉起，故障恢复时间不可控。
  • 无故障溯源能力：脚本只做重启操作，不会留存服务崩溃时的日志、系统资源状态快照，后续排查故障根因非常困难。
  • 无熔断机制：如果Solr是因为磁盘满、内存不足、配置错误这类持续性问题崩溃，脚本会反复重启失败，还可能刷大量日志占满剩余磁盘空间。

如果要适配核心生产场景，可以做如下优化：

• 替换cron轮询为systemd原生的Restart=on-failure配置，让systemd在服务异常退出时秒级自动拉起，响应速度远高于定时任务。
• 健康检查逻辑增强，不要只判断进程是否存在，增加端口连通性检测、Solr管理接口探活（比如请求本地8983端口的admin接口校验返回值是否正常）。
• 增加重启前的现场留存逻辑，自动备份故障时刻的Solr运行日志、系统内存/磁盘/进程快照，方便后续排查根因。
• 增加熔断告警规则，短时间内连续重启失败就停止尝试，触发告警通知运维人员介入。

内容的提问来源于stack exchange，提问作者Will