Linux 的 yum 源怎么「重启」？源不是服务，你真正要做的是这三件事
不少人遇到 yum 报错，第一反应是上网搜「怎么重启 yum 源」——这个搜索词本身就藏着一个误解：yum 源不是一个常驻的服务或进程，它是躺在 /etc/yum.repos.d/ 目录下的一批仓库配置文件；yum 是每次敲命令时才去读这些配置的工具，用完就走。没有进程在跑，自然没有「重启」一说。但搜这个词的人背后都有真实诉求，拆开来其实是三种情况，各有各的解法。
「重启」背后的三种真实需求
第一种：缓存坏了，想清一遍重来。yum 会把仓库的元数据缓存在本地，缓存半新不旧或者损坏时，装包会报版本对不上、校验失败一类的错。这种情况清缓存重建就行，三步：
- yum clean all——把本地旧元数据清掉；
- yum makecache——重新从源上拉取一套新元数据；
- yum repolist——看仓库列表，各仓库状态正常才算活。
注意 clean 和 makecache 的分工：前者处理「旧的、坏的」，后者负责「拉新的」。只 clean 不 makecache，下次操作时还是要现场拉，等于白清；只 makecache 不 clean，坏缓存可能还压着底。
第二种：换了源，想让新源生效。改过 repo 文件（换镜像、加仓库）之后，同样走一遍 clean all 加 makecache——这就是「换源后重载」的全部内容，不需要重启任何东西，因为 yum 下次执行自然读新配置。
第三种：网络源根本连不上。这时先别动配置，拿浏览器或 curl 直接访问一下镜像地址看看：地址 404，说明这个镜像失效了，得换源；证书报错，是源的证书过期或者本机时间不对；连接超时，是网络或防火墙的事。还有一种如今越来越常见的情况：系统过了生命周期——比如 CentOS 7 停止维护之后，官方原地址的包整体挪进了归档库，老配置再去原地址拉包就是一片 404，这时候把源指向归档地址才是正解。
什么时候才真的需要动源
日常来说，缓存层面的三板斧（clean、makecache、repolist）能解决大多数「抽风」。真要动源文件，通常是三种硬情况：镜像大面积失效（404 成片出现）、证书过期没人管、多个源同时供一个包导致优先级打架（装出来的版本不可控）。除了这三种，多数时候问题不在源本身。另外说明一句：如果 yum 已经完全不能用、需要整套重置源配置，那是另一套完整实操，本篇只管「重启」这个诉求的概念纠偏，两篇不混。
存量主机的时代账
这套东西看着琐碎，放到企业存量主机上就是实打实的风险：一批跑了七八年的服务器，系统陆续到达停止维护的年龄，源一个接一个失效，哪天急着装个补丁包才发现 yum 早就拉不动了。贵州诚鑫致达科技接手存量服务器运维时，会把在管主机的系统生命周期和源状态盘点成一张底账，到达年限的系统提前切换归档源，不让「装不上包」发生在急着用的那一刻。
下次 yum 报错，先别搜「重启」——判断自己是三种需求里的哪一种，再动手。
