ollama.service 在哪里

很多人装完 Ollama，想改监听地址、模型目录或者服务重启策略，`systemctl edit ollama` 一敲发现服务压根不存在，翻遍 `/etc/systemd/system` 也没有那个文件。这篇不绕概念，直接按「先确认谁在管进程、再顺藤摸瓜找文件路径、最后按发行版对号入座」的顺序走一遍，让你在几分钟内定位到 service 文件，顺便搞清找不到时的几种常见原因。

很多人装完 Ollama，想改监听地址、模型目录或者重启策略，`systemctl edit ollama` 一敲，发现服务压根不存在，翻遍 /etc/systemd/system 也没有那个文件。先别急着怀疑自己装错了，Linux 上 Ollama 不一定由 systemd 接管，脚本安装、手动二进制启动、Docker 容器这三种方式都不会生成 systemd 单元文件。

这篇不绕概念，直接按「先确认谁在管进程、再顺藤摸瓜找文件路径、最后按发行版对号入座」的顺序走一遍。你在几分钟内能定位到 service 文件，找不到时也知道是哪种原因。要改监听地址这类参数，别急着开编辑器，先确认你要改的东西是不是该写在这里。

先搞清：为什么你找不到 ollama.service

最常见的情况不是文件藏得深，而是根本没有这个文件。Ollama 在 Linux 上有三种常见存在方式：官方安装脚本会顺手帮你注册一个 systemd 服务；直接下二进制手动跑，就只是当前 shell 里的一个前台进程；Docker 里跑，进程活在容器里，宿主 systemd 对它一无所知。三种方式的「服务」概念完全不同。

• 脚本或包管理器安装：systemd 里能查到 ollama 服务，有对应的单元文件，只不过路径不一定在你想的那个目录。
• 手动二进制启动：没有单元文件，进程的父进程通常是你登录的 shell 或终端，关掉终端进程可能就没了。
• Docker 容器方式：没有宿主单元文件，容器有重启策略，但那是 docker 的事，和 systemctl 不共享一套配置。
• 还有一种绕的情况：装过又卸、换过安装方式，目录里留着半截配置，看着像有其实没生效。

定位顺序：四步锁定 service 文件真实路径

1. 第一步：查服务是否已注册用 systemctl status ollama 看有没有输出，再用 systemctl list-unit-files 加过滤条件看单元列表里有没有 ollama。能查到就说明 systemd 在管它，查不到基本可以判定是手动或容器起的。
2. 第二步：让 systemd 自己报出文件路径用 systemctl show 类命令查看单元的 FragmentPath 和 DropInPaths 字段，它会直接告诉你当前生效的单元文件在哪个位置、叠加了哪些覆盖片段。这比手动 find / -name ollama.service 全盘搜更快也更准，因为 find 可能搜出一堆历史残留的同名文件。
3. 第三步：区分静态单元和覆盖片段包管理器装出来的是一份静态单元文件，位置由发行版决定；用 override 做的改动则放在覆盖目录里，以 drop-in 片段形式叠加。两者路径不同，改错地方就会出现「我明明改了却没用」。
4. 第四步：倒回去看进程如果 systemd 完全不知情，就查进程树：找 ollama 进程的 PID，看它的父进程和完整启动命令。启动命令里如果带 --host 这类参数，说明参数是命令行直接给的，和你找的配置文件没关系。

这四步的价值在于顺序不能乱。跳过第一步直接翻目录，很容易在一个不生效的旧文件上浪费时间；跳过第二步手动全盘搜，得到的结果可能根本不是 systemd 实际加载的那个。

常见落点对照表：不同安装方式文件在哪

表里有个规律值得记：凡是包管理器能装的东西，它的单元文件就归包管理器管。你直接编辑，下次升级被覆盖是大概率事件。想长期稳定的改动，统一走覆盖片段这条路。有人会想，那我先改原文件、记下来以后手动恢复行不行？小规模临时用可以，多台机器或团队协作就别这么干，没人记得住。想要一份随系统版本走的对照，可以到 指南中心（/guides） 看看有没有更新的整理；具体到某次改动带来的资源占用差异，去 速度测试（/tools/speed-test） 按当时的机器情况跑一遍，别照搬别人的结论。

找到之后怎么改：该动哪个文件、别动哪个

先说原则：包管理器装的单元文件不要直接改，升级会被覆盖。正确的做法是创建一个覆盖片段，只写你要盖掉的那几行，systemd 会把原文件和你这份片段合并起来用。这样升级时原文件怎么变都不影响你的配置，排查起来也能一眼看出改动来自哪。

覆盖片段（drop-in）

放在专门的覆盖目录下的小文件，只写要覆盖的配置项，和原单元文件合并生效

重载守护进程

改完单元文件或覆盖片段后，需要让 systemd 重新读取这些文件，否则它用的还是缓存的旧配置

重启服务

在重载之后让服务进程按新配置重新启动，这一步才真正让改动落到运行中的进程上

顺序很重要：先重载、再重启。只重启不重载，systemd 拿的还是它缓存里的旧配置，你看着服务重启了，实际参数没变，会误以为改动无效。重载之后再重启，才是一次干净的生效流程。

• 先确认你改的是被实际加载的片段：通过 systemctl 回读覆盖片段列表，看路径对不对得上。
• 环境变量类配置（监听地址、模型目录、常驻行为）优先用覆盖片段注入，别写死在命令行里。
• 改完执行重载守护进程，再重启服务，两步都做完再做验证。
• 验证时看进程实际生效的参数，不要只看配置文件里写了什么。

确实没有 service 文件时的三种替代方案

确认 systemd 没接管、你又希望它统一管理，那可以自己补一份最小可用的单元文件。放在系统级单元目录，内容涵盖启动命令、重启策略、运行用户这几项就够，不需要写得很复杂。写完重载守护进程，再启动并设置开机自启即可。

# 思路示意：先确认 systemd 是否知情，再决定要不要自己补单元文件
systemctl status ollama
systemctl list-unit-files | grep -i ollama
# 需要看生效路径时，让 systemd 自己报出来
systemctl show ollama -p FragmentPath -p DropInPaths

选哪个不是看哪个更高级，而是回答三个问题：要不要开机自启、崩了要不要自动拉起、日志想不想进 journald。三个都要，就补单元文件；本来就在容器里跑，就把容器平台的重启策略配好；只是临时验证功能，前台跑就够，先别给自己加维护负担。

排查顺序清单：按这个顺序走不会白忙

• 先确认进程活着没有：查进程是否存在，不存在就先看启动失败的原因。
• 再看是谁把进程拉起来的：systemd、shell、还是容器运行时，这决定了你该去哪个配置体系里找。
• 然后去找配置文件：确认体系之后再定位具体文件，避免在错误的目录里翻。
• 服务起不来时优先看日志输出，环境变量写错比路径写错更常见。
• 改完没效果，先确认改的是被实际加载的那个片段，同名文件可能存在于多个目录。
• 多种安装方式并存会互相打架，这种情况先卸干净再重装，比逐个排查省时间。

这个顺序的核心是「先看运行态、再看管理方式、最后看配置」。反过来做，你会在还没确认 service 是谁在管的情况下改配置，改完发现根本没加载，return 到原点。

改完怎么验证：三个自查动作

1. 回读生效的单元与覆盖片段用 systemctl show 查看 FragmentPath 和 DropInPaths，确认你的改动确实在被加载的列表里。
2. 从进程侧看实际参数查进程的完整启动命令和监听端口，确认它真的用上了新配置，而不是只改了文件。
3. 演练重启与开机自启先重启服务看是否自动拉起，需要开机自启的再验证一次开机行为，别等下次重启才发现没生效。

做完这三步再回去改下一次，你会发现每次都是数据说话，而不是猜。顺手把当前生效的路径记在笔记里，下次改的时候直接对照，省得重新走一遍排查。

什么情况下这套方法不适用

这套思路建立在 Linux 加 systemd 的前提上。macOS 和 Windows 不用 systemd，服务管理的机制是另一套，路径和命令都对不上，照搬只会更乱。跨平台混合部署的团队要分清每台机器用的哪套机制，别拿一台机器上的结论去套所有机器。

另外两种情况也绕开这套方法：在 Kubernetes、Nomad 这类编排里跑 Ollama，没有宿主机单元文件这个概念，配置走的是编排清单；开发机上临时跑一个实例，本来就不该配成系统服务，硬配只会让后续排查更乱。判断标准很简单：这台机器上这个进程是不是需要长期、自动、可复用，答案是否定就别动 systemd。