别着急，我来给你梳理几个靠谱的排查方向，一步步定位到这个自启容器的启动源并禁用它：

1. 先排查Docker自身的容器自启配置 #

这是最常见的情况——很多人创建容器时会加上--restart=always或--restart=unless-stopped参数，让Docker守护进程自动在开机时启动容器。

• 先找到目标容器的名称或ID：运行 docker ps -a 列出所有容器，找到那个开机自启的容器。
• 查看它的重启策略：运行 docker inspect <容器名/容器ID>，在输出中找到RestartPolicy字段，如果Name是always或unless-stopped，说明是Docker自身管理的自启。
• 禁用自启：直接运行 docker update --restart=no <容器名/容器ID>，这样下次开机它就不会自动启动了。

2. 检查Docker Compose的自启服务 #

如果你是用Docker Compose部署的容器，可能配置了systemd服务或者用了Compose的自启命令：

• 先搜索系统中是否有Docker Compose的配置文件：运行 find / -name "docker-compose*.yml" -o -name "docker-compose*.yaml"（可以加上-type f限制为文件），找到可能的配置文件后，查看里面的服务是否对应目标容器。
• 检查systemd中的Compose服务：运行 systemctl list-unit-files | grep -i compose，如果看到类似docker-compose@<服务名>.service或者自定义的Compose服务，运行 systemctl cat <服务名>查看服务的启动命令，确认是否关联目标容器。
• 禁用该服务：如果确认是它，运行 systemctl disable --now <服务名>，停止当前运行的服务并禁止开机自启。

3. 排查systemd自定义服务 #

很多用户会写自定义的systemd服务来启动Docker容器，你可以这样查：

• 列出所有和容器/Docker相关的服务：运行 systemctl list-units --type=service --all | grep -i -E "docker|container"。
• 对可疑的服务，查看其配置文件：运行 systemctl cat <服务名>，看ExecStart字段的命令是不是启动目标容器的docker run或docker compose up命令。
• 禁用服务：确认后运行 systemctl disable --now <服务名> 即可。

另外，也可以直接搜索systemd服务目录里的文件：find /etc/systemd/system /lib/systemd/system -name "*.service" -exec grep -l "docker run\|docker compose" {} \;，快速定位可能的服务文件。

4. 通过系统日志定位启动源 #

如果上面的方法都没找到，可以通过开机日志来追踪容器的启动过程：

• 查看本次开机的Docker服务日志：journalctl -b -u docker.service，里面会记录Docker守护进程启动的容器信息，能看到容器启动的触发来源。
• 直接搜索容器相关的日志：journalctl -b | grep -i <容器名/镜像名>，从日志里找启动命令的上下文，比如是哪个脚本、服务触发的启动。

5. 检查其他可能的自启途径 #

如果还是没找到，再排查这些容易忽略的地方：

• 用户级自启：检查~/.config/autostart/目录下的.desktop文件，看有没有启动Docker容器的脚本；还有用户的~/.bashrc、~/.profile等登录脚本（如果系统设置了自动登录，这些会在开机时执行）。
• systemd定时器：替代传统crontab的定时任务，运行 systemctl list-timers --all，看有没有定时启动容器的任务。
• 全局脚本目录：检查/etc/profile.d/、/etc/bash.bashrc这些全局脚本文件，看是否有启动容器的命令。

这些方法都是安全的，不会导致系统无法启动——禁用服务或修改自启配置只是停止自动触发，不会删除任何关键文件，你随时可以恢复配置。

备注：内容来源于stack exchange，提问作者Ivan Krivyakov