Ansible为何列出状态为not-found的服务？原因解析

一、"not-found"状态的含义 #

当Ansible的service facts中某个服务的status字段为not-found时，代表systemd能识别该服务名称，但对应的服务单元文件不存在。这种情况常见于：

• 服务曾经安装启用过，后续被卸载但systemd残留了名称记录
• 服务是systemd的虚拟服务条目，没有实际的单元文件
• 服务单元文件被手动删除，但systemd缓存中仍保留该服务名称

二、为什么不存在的服务会出现在service facts里 #

这是Ansible结合systemd特性的结果：
Ansible的ansible.builtin.service_facts模块会调用systemd接口查询所有已知服务条目——systemd会保留一些曾经存在、或有内部引用的服务名称记录，哪怕对应的单元文件已经不存在。Ansible会将这些记录全部纳入service facts，并用not-found状态标记出那些无实际单元文件的服务，而非直接忽略。

三、原剧本报错的原因 #

你最初设置的条件when: "item in services"仅判断服务名称存在于service facts中，但not-found状态的服务没有实际可操作的单元文件。当ansible.builtin.systemd模块尝试对其执行stopped或enabled: false操作时，systemd找不到对应的服务单元，就会抛出"service not found"错误。

四、正确的处理逻辑 #

你后续修改的条件是合理的：

when: "(item in services) and (services[item].status != 'not-found')"

这个条件既确保服务在facts中有记录，又过滤掉了无实际单元文件的not-found状态服务，避免执行无效的systemd操作。

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