Ubuntu上使用systemd管理服务与故障恢复

在Ubuntu生产环境中，systemd服务启动失败或者进程异常退出后无法自动恢复，是运维中最让人头疼的问题之一。很多人配置了service文件，但服务挂掉后就是起不来，或者重启逻辑不符合预期。这通常不是systemd本身的问题，而是对Restart策略、依赖关系以及故障排查流程理解不到位造成的。下面直接拆解这些问题，给出具体配置方法和恢复机制。

systemd管理服务的核心是单元文件（unit file），通常存放在/etc/systemd/system/或/lib/systemd/system/目录下，以.service为后缀。一个典型的服务单元文件包含Unit、Service和Install三个主要段。Unit段定义服务的描述和依赖关系，Service段定义执行的具体命令和重启行为，Install段定义服务如何被启用。很多配置问题都出在Service段的参数设置上，尤其是Type和Restart策略的搭配。

systemd的Service段中Type参数决定了systemd如何判断服务是否启动成功。Type=simple是默认值，systemd认为ExecStart启动的进程只要不立即退出就算成功，但这对于需要初始化时间的服务来说太粗糙了。Type=forking适用于传统后台守护进程，进程会fork一个子进程后退出父进程，此时需要配合PIDFile参数指定pid文件路径。Type=notify要求服务在初始化完成后主动通过sd_notify通知systemd，这是最可靠的方式，但需要服务代码本身支持。Type=oneshot适用于执行一次就退出的任务，通常配合RemainAfterExit=yes使用。选择错误的Type会导致systemd误判服务状态，比如一个需要长时间初始化的Java应用用了Type=simple，systemd可能在其还未完全就绪时就认为启动成功，后续健康检查失败时又无法正确触发重启。

服务异常退出后的自动恢复完全依赖于Restart和RestartSec参数。Restart=no表示不自动重启，Restart=always表示无论退出原因如何都重启，Restart=on-success仅在退出码为0时重启，Restart=on-failure在退出码非0或进程被信号终止时重启，Restart=on-abnormal在进程被信号终止、超时或看门狗触发时重启，Restart=on-watchdog专门针对看门狗超时。实际生产环境中，Restart=on-failure是最常用的选择，配合RestartSec=5s设置重启间隔。但需要注意，如果服务在短时间内反复崩溃，systemd默认的启动速率限制会阻止无限重启，通过StartLimitBurst和StartLimitIntervalSec可以调整这个阈值，例如StartLimitBurst=5和StartLimitIntervalSec=10s表示10秒内最多允许5次启动尝试。

Restart=always只能检测进程是否存活，但进程活着不代表服务正常。systemd的看门狗功能可以解决这个问题。配置WatchdogSec=30s后，服务需要每隔30秒内通过sd_notify发送WATCHDOG=1信号，如果超时未收到，systemd会认为服务已经僵死并强制终止进程，然后根据Restart策略重启。对于不支持sd_notify的应用程序，可以通过ExecStartPost启动一个外部健康检查脚本，利用Type=notify的代理模式实现类似效果。这种机制对于内存泄漏导致的服务缓慢僵死、死锁等问题特别有效，远比简单的进程存活检测可靠。

Unit段的After和Requires、Wants经常被混淆。After仅定义启动顺序，不建立依赖关系；Requires定义强依赖，被依赖的服务启动失败会导致当前服务启动失败；Wants定义弱依赖，被依赖的服务启动失败不影响当前服务。对于数据库依赖的服务，应该使用Requires=postgresql.service配合After=postgresql.service，这样既保证了启动顺序，又确保了数据库不可用时服务不会以残缺状态运行。更精细的控制可以通过ExecStartPre执行前置检查脚本，比如用pg_isready检测数据库是否真正可接受连接，而不是仅依赖systemd的依赖关系。

服务启动失败时，journalctl是最直接的排查工具。journalctl -u 服务名 -b可以查看当前启动周期内该服务的所有日志，-f参数可以实时跟踪。关键是要关注ExecStartPre和ExecStart的输出，很多启动失败是因为环境变量缺失或工作目录权限问题。systemd默认会清理进程环境，如果服务依赖特定的PATH或LD_LIBRARY_PATH，需要在Service段通过Environment或EnvironmentFile显式设置。另外，PrivateTmp=yes、ProtectSystem=full等安全加固选项虽然提高了安全性，但也可能导致服务无法访问预期路径，排查时需要暂时关闭这些选项来定位问题。

systemd可以精细控制服务的资源使用，这本身就是一种故障预防手段。MemoryMax限制最大内存使用量，超过后进程会被OOM Killer处理，配合Restart策略可以实现内存泄漏后的自动恢复。CPUQuota限制CPU使用百分比，TasksMax限制最大线程数。对于容易产生僵尸进程的服务，KillMode=control-group可以确保停止服务时清理所有子进程。TimeoutStopSec设置停止超时时间，默认90秒，对于需要长时间清理资源的服务要适当调大，否则systemd会强制发送SIGKILL。

对于需要运行多个实例的服务，systemd的模板功能非常实用。创建文件如worker@.service，其中%i会被实例名替换。例如ExecStart=/usr/bin/worker --instance %i，启动时使用systemctl start worker@1和systemctl start worker@2。每个实例拥有独立的cgroup和资源限制，一个实例的故障不会影响其他实例。这种模式在微服务架构中特别常见，配合PartOf参数可以将多个实例绑定到一个目标单元，实现统一管理。

以下是一个完整的Flask应用服务单元文件示例，展示了上述各种机制的综合应用：

[Unit]
Description=Flask Web Application
After=network-online.target postgresql.service
Requires=postgresql.service
Wants=network-online.target

[Service]
Type=notify
User=www-data
Group=www-data
WorkingDirectory=/opt/myapp
EnvironmentFile=/etc/myapp/environment
ExecStartPre=/usr/bin/bash -c 'until pg_isready -h localhost; do sleep 1; done'
ExecStart=/usr/bin/python3 -m uvicorn app:app --host 0.0.0.0 --port 8000
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
WatchdogSec=30s
StartLimitBurst=5
StartLimitIntervalSec=10s
MemoryMax=512M
CPUQuota=200%
TasksMax=100
TimeoutStopSec=30s
KillMode=mixed
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/var/log/myapp /var/lib/myapp
NoNewPrivileges=yes

[Install]
WantedBy=multi-user.target

这个配置中，Type=notify要求应用支持sd_notify，如果不支持可以改为Type=simple并移除WatchdogSec。ExecStartPre中的pg_isready循环确保数据库真正可用后才启动应用。Restart=on-failure配合StartLimitBurst防止无限重启风暴。MemoryMax和CPUQuota提供资源隔离，ProtectSystem和ReadWritePaths实现最小权限原则。部署后使用systemctl daemon-reload重载配置，systemctl enable --now myapp.service立即启动并设置开机自启。

对于某些需要复杂恢复逻辑的场景，可以在Service段使用ExecStopPost执行清理脚本，或者在ExecStartPre中加入状态恢复逻辑。例如，如果服务依赖一个锁文件，可以在启动前检查并清理残留的锁文件。更高级的做法是编写一个包装脚本作为ExecStart，脚本内部实现健康检查、自动重启、状态上报等逻辑，systemd只负责最基本的进程管理。这种分层设计让故障恢复逻辑更灵活，也便于测试和维护。

systemd本身可以通过OnFailure参数指定服务失败时触发的补救单元。创建一个补救服务，例如myapp-failure-handler.service，在其中调用发送告警的脚本。在myapp.service的Unit段添加OnFailure=myapp-failure-handler.service，这样当myapp进入failed状态时，自动触发告警。结合journalctl的--since参数，补救服务可以提取最近一段时间的错误日志并发送给运维人员。这种机制实现了从故障检测到告警通知的闭环。

systemd的功能远不止启动和停止服务，它的cgroup集成、资源控制、依赖管理、看门狗机制构成了一个完整的服务生命周期管理系统。掌握这些配置后，Ubuntu上的服务管理会从被动救火转变为主动预防，大部分故障都能被自动恢复，运维压力会大幅降低。