在 Linux 上装完 Ollama，想用 systemctl status ollama 看一眼状态，结果提示 Unit ollama.service could not be found——很多人第一反应是装坏了。其实多半不是坏了，而是你的安装方式或发行版根本没给你这个单元文件。这篇按「先判断属于哪种情况，再选启动方式」的顺序讲，最后给一份排查与自启清单。
在 Linux 上装完 Ollama，敲 systemctl status ollama，回你一句 Unit ollama.service could not be found，第一反应通常是「装坏了」。多数情况下没坏，只是你的装法或发行版根本没提供这个单元文件。先别急着重装，重装一遍大概率还是同样一句话。
这篇按「先判断属于哪种情况，再选启动方式」的顺序讲。判断只用几条命令，选路只看你的场景是临时调试还是长期开机自启，最后给一份能照着走的排查清单。全程不需要你懂 systemd 内部原理，知道几个文件放哪就行。
先分清：是没装这个单元，还是你根本没装对
systemd 单元不属于 Ollama 本体。官方安装脚本、发行版包管理器、手动解压二进制，三种装法产出的东西不一样：有的会顺手放一个服务单元，有的只丢一个可执行文件。所以「命令能用、服务找不到」是很常见的组合，不代表安装残缺。
| 现象 | 大概率原因 | 下一步动作 |
|---|---|---|
| systemctl 命令本身就不存在 | 容器镜像、WSL、精简系统或非 systemd 发行版 | 别找单元文件了，直接看下一节的三种起法 |
| systemctl 能跑，但查不到 ollama 这个单元 | 装法没带服务单元，或单元名不叫这个 | 手动确认可执行文件位置，必要时自己写单元 |
| 单元存在但起不来 | 路径、用户、环境变量对不上 | 按日志逐条核对，先看监听和模型目录 |
- 第一步看 systemctl 这条命令在不在，不在就说明系统不用 systemd 管服务，报同样的话完全正常
- 第二步找可执行文件在哪，用 which 或直接看安装脚本落到哪个目录，systemd 只认绝对路径
- 第三步在常见单元目录里搜一遍有没有含 ollama 字样的文件，确认是「没有」还是「名字不同」
- 第四步再怀疑安装是否完整：能跑起来出字，就说明本体没问题，缺的只是服务包装
没有 service 的三种起法，按场景挑
选哪种起法只看两件事：你要跑多久，以及终端关了之后还需不需要它活着。临时验证和长期常驻，做法完全不同，硬套一种会给自己找麻烦。
- 前台手动起直接在终端执行可执行文件，日志就在屏幕上，报错第一时间能看到；适合调参和排障。缺点是终端一关进程就断，不能算常驻。
- 后台加日志用 nohup 或把输出重定向到文件，再让它后台跑。适合临时长时间占用；你要自己管进程号、自己看日志文件、自己处理日志变大，机器重启后也不会自己回来。
- 自己写一个服务单元手写一份单元文件放进系统级或用户级目录，交给 systemd 管生命周期，是长期跑最省事的路子。用户级单元不需要 root，但要留意登录会话退出后它还在不在。
不管选哪种，先把模型存放目录、监听地址、显卡选择这几项定死。手动跑时靠 shell 里临时的变量，一换终端或变成服务就丢，表现出来是「模型不见了」或者速度突然掉下来，其实只是环境不同。
把环境变量和服务绑在一起，避免重装后失联
环境变量是这类问题里最容易埋雷的地方。手动启动时它从当前 shell 继承，一旦改成服务启动，继承链断了，行为就跟之前不一样。所以长期用的配置不要靠 export，要写进服务自己的环境段或用户级环境文件。
- 监听地址与端口
- 决定别的程序能不能连上；写死成固定值，别让它每次随机变
- 模型存放目录
- 换过位置一定要同步改，并且确认新目录可写、磁盘放得下
- 可见的加速设备
- 不指定时可能悄悄回落到只用处理器，表现是速度突然变慢
权限问题特别容易误判：目录不可写时，拉模型往往不是报权限拒绝，而是报各种看不懂的失败。所以改完路径先手动在新目录里写一个文件试试，能写再继续。
- 多用户机器上区分系统级和用户级服务，避免一个人的配置把另一个人的覆盖掉
- 用户级服务要确认会话注销后是否继续运行，否则看着在跑、实际人一走就停
- 重装或升级后回头核对一遍这几项变量，别默认它还在
- 把这些配置记在一处，换机器时照抄，比事后靠回忆排查省时间
一份能照着走的排查与验收清单
排查顺序比记命令更重要。先确认「到底有没有在跑」，再确认「能不能正常出结果」，最后才验证「重启后还在不在」。顺序反了容易在错误的方向上花时间。
- 确认进程与端口先看进程在不在、端口通不通。很多人以为服务没起，其实起了，只是单元名查错了，或者进程以另一种方式在跑。
- 看日志手动起的看终端输出，交给 systemd 的看它的日志，自己写重定向的看那个日志文件。日志里的报错通常直接指向配置哪一项不对。
- 发一条最小请求进程活着不等于能用。发一条最小的请求，确认真的能返回结果，这才算通过。
- 重启一次机器验证自启是否真的生效。这里最容易翻车的是用户级服务依赖登录会话，人没登录它就没起来。
另外，如果你在意的是模型速度、显存占用这类实际表现，而不是启动方式本身，那排查方向完全不同，别把两件事混着做。想把配置和性能一起看，可以先到站内的工具目录里挑一个合适的检测方式，再对着数字判断。
下一步如果你已经跑通了，想顺带对照一下接口表现和中转方案的差异，站内的目录与价格追踪页能帮你把当前的选择放在同一张表里比较，省得来回翻文档。→常见问题
装了 Ollama 但没有 ollama.service，是不是装错了？
不一定。单元文件取决于安装方式和发行版，手动解压二进制、容器镜像、非 systemd 的系统都不会自带。先看 systemctl 在不在、有没有对应 unit，再决定是手写一个还是换启动方式；能正常出字就说明本体没问题。
自己写的 service 开机后没起来，从哪查？
先看这次是不是用户级单元——用户级服务常常要等登录会话，重启后没登录就不跑。再确认 unit 里的可执行文件路径写的是绝对路径、环境变量写在单元里而不是 shell 里，最后翻日志看具体报错。
手动前台能跑，做成服务就变慢，为什么？
多半是环境变量没带过去，比如模型目录和 GPU 可见设备丢了，服务回落到 CPU 或重新下载模型。把这些变量写进单元文件，重启服务后再打一条请求，对比耗时是否回到手动的水平。
