Ubuntu下Docker容器以Service启动失败，对比--restart策略

我在Ubuntu服务器上通常通过创建systemd Service并执行预先在终端验证过的docker run命令启动Docker容器。但近两天遇到问题：这些docker run命令在终端执行正常，通过Service运行却失败，服务日志仅显示如下内容：

ABC.service: Scheduled restart job, restart counter is at 5.
Stopped ABC.
ABC.service: Start request repeated too quickly.
ABC.service: Failed with result 'start-limit-hit'.
Failed to start ABC.

多个无关的容器以Service启动时均出现此问题，但部分Docker服务仍能正常运行。现咨询：

1. 是否有人遇到类似问题，或能指明排查根因的方向？
2. 我使用Service的核心需求是实现容器重启，能否用docker run命令的--restart always参数替代？这么做是否有弊端？

问题1：排查方向 #

• 检查systemd服务的依赖配置：不少人碰到过同款问题，核心原因是systemd服务没正确依赖docker.service或containerd.service。终端里Docker已经就绪，但systemd启动你的服务时，Docker可能还没完成初始化，导致docker run执行失败，触发重启循环，最终触发start-limit-hit限制。可以在你的.service文件的[Unit]段添加：

  After=docker.service containerd.service
  Requires=docker.service
  

• 查看完整服务日志：用journalctl -u ABC.service -f -n 50拉取更详细的日志，你贴的错误只是最终触发的限制，实际启动失败的根源（比如权限不足、环境变量缺失、挂载路径不存在等）大概率藏在更早的日志里。
• 核对服务执行权限：终端是用当前用户执行命令，但systemd服务默认可能用其他用户运行。如果服务用非root用户，可能没有Docker执行权限，或者无法访问容器需要的挂载目录。可以先在.service的[Service]段加User=root测试，或者给目标用户添加Docker组权限。
• 检查容器状态：终端执行docker run时如果容器已存在会直接报错，而systemd服务每次启动都会重复执行这个命令，第一次失败后重启会重复触发错误，形成循环。可以把命令改成docker start ABC，或者在docker run前加docker rm -f ABC（注意数据风险），也可以用docker run --rm确保每次启动都是全新容器。

问题2：用--restart always替代的可行性与弊端 #

• 完全可以替代：如果你的核心需求只是容器重启，docker run --restart always是Docker原生的重启策略，只要Docker守护进程在运行，容器退出时就会自动重启，不需要额外配置systemd服务。
• 弊端分析：
  • 缺失systemd统一管理能力：没法通过systemctl统一控制容器的启停，也不能和其他systemd服务设置依赖（比如容器需要等某个数据库服务启动后再运行）。
  • 日志分散：容器日志需要用docker logs查看，没法通过journalctl统一检索，排查问题时需要切换工具。
  • 启动顺序无法精准控制：Docker的重启策略是守护进程启动后就启动容器，如果你需要容器在NFS挂载、系统数据库等服务之后启动，原生策略做不到，必须靠systemd配置依赖。
  • 精细控制不足：systemd可以配置服务的CPU/内存资源限制、重启延迟、启动超时等，Docker的重启策略没有这些精细化控制选项。

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