升级Python后yum报错怎么修复：修改脚本解释器路径

月亮慢半拍

发布时间：2026-10-24| 4人浏览过

原创

在 CentOS 7 或基于 RHEL 7 的系统中，当管理员为了运行新项目而升级了全局 Python（例如把 /usr/bin/python 软链接指向了 Python 3.x）之后，再次执行 yum 命令往往会立即抛出 SyntaxError: invalid syntax 错误。核心原因在于系统的包管理器 yum 底层强依赖 Python 2 的语法和系统库，直接覆盖系统默认解释器会导致脚本解析中断。最稳妥、立竿见影的解决办法并不是推倒重来，而是针对性修改 yum 及其依赖脚本的第一行解释器路径（Shebang），显式指定使用系统原本保留的 /usr/bin/python2。

一、报错表现与底层冲突原理

在 Linux 终端执行任何 yum 相关命令时，最常见的报错信息如下所示：

[root@server ~]# yum makecache
  File "/usr/bin/yum", line 30
    except KeyboardInterrupt, e:
                            ^
SyntaxError: invalid syntax

如果继续进行软件包下载或更新，还可能在后台触发依赖组件的二次报错：

  File "/usr/libexec/urlgrabber-ext-down", line 28
    except OSError, e:
                  ^
SyntaxError: invalid syntax

这两处报错的根源完全一致：Python 2 允许在捕获异常时使用逗号分隔异常类与变量实例（即 except Exception, e:），而 Python 3 全面废弃了该语法，强制要求使用 except Exception as e:。当 /usr/bin/python 被重定向到 Python 3 时，Python 3 的语法分析器在编译阶段就会直接判错退出。

升级Python后yum报错怎么修复：修改脚本解释器路径 — 图 1：Python 升级后系统符号链接与解释器版本语法冲突示意图

二、故障排查与需要修复的关键文件定位

在动手修改之前，先按合理的排查链路核对当前系统的实际状态。很多用户只修改了 /usr/bin/yum 这一个文件，结果在运行下载任务时依然遇到 urlgrabber-ext-down 报错。因此，必须完整掌握涉及的所有关键位置。

三、修改脚本解释器路径的具体操作步骤

修复的核心思想是“解绑全局链接，指定固定版本”。只要将脚本第一行的 #!/usr/bin/python 显式指定为 #!/usr/bin/python2（或具体的 #!/usr/bin/python2.7），脚本在被触发时就不会再去寻找被修改后的全局 python 软链接。

详细操作流程

第一步：核实 Python 2 路径并备份原始文件

在修改系统核心文件前，务必先进行备份，以防误操作。执行以下命令核实原生解释器并创建副本：

[root@server ~]# ls -l /usr/bin/python2*
lrwxrwxrwx 1 root root      9 Oct 20 10:00 /usr/bin/python2 -> python2.7
-rwxr-xr-x 1 root root   7144 Jun 28 2022 /usr/bin/python2.7

[root@server ~]# cp /usr/bin/yum /usr/bin/yum.bak
[root@server ~]# cp /usr/libexec/urlgrabber-ext-down /usr/libexec/urlgrabber-ext-down.bak

只要确认 /usr/bin/python2 仍然存在并正确指向 Python 2.7 解释器，就可以直接将这个路径写入脚本头部。

第二步：修改 /usr/bin/yum 解释器路径

可以使用文本编辑器（例如 vi /usr/bin/yum）直接打开文件，将第一行内容：

#!/usr/bin/python

修改为：

#!/usr/bin/python2

或者直接在终端中运行一条 sed 命令完成原地替换：

[root@server ~]# sed -i '1s|#!/usr/bin/python|#!/usr/bin/python2|' /usr/bin/yum

第三步：修改 /usr/libexec/urlgrabber-ext-down 解释器路径

同样，打开 /usr/libexec/urlgrabber-ext-down 文件，将其首行的 #!/usr/bin/python 修改为 #!/usr/bin/python2。使用 sed 命令执行如下：

[root@server ~]# sed -i '1s|#!/usr/bin/python|#!/usr/bin/python2|' /usr/libexec/urlgrabber-ext-down

第四步：检查其他可能受影响的 yum 扩展工具

如果在日常运维中经常使用 yum-config-manager、yumdownloader 或 repoquery 等 yum-utils 工具包中的命令，它们同样以 #!/usr/bin/python 开头。如在调用时也遇到类似报错，只需使用同样的方法，将其首行修改为 #!/usr/bin/python2 即可：

[root@server ~]# sed -i '1s|#!/usr/bin/python|#!/usr/bin/python2|' /usr/bin/yum-config-manager

四、结果验证与排查确认

修改完成后，必须执行完整的测试命令以验证修复效果。不要仅仅执行 yum 打印帮助，而要实际拉取元数据或执行查询，确保网络模块与本地模块均能正常调用：

[root@server ~]# yum clean all
Loaded plugins: fastestmirror
Cleaning repos: base extras updates
Cleaning up list of fastest mirrors

[root@server ~]# yum makecache
Loaded plugins: fastestmirror
Determining fastest mirrors
base                                                     | 3.6 kB     00:00
extras                                                   | 2.9 kB     00:00
updates                                                  | 2.9 kB     00:00
Metadata cache created.

当输出显示“Metadata cache created”且中间没有抛出任何 SyntaxError 时，说明 yum 主程序和底层的 urlgrabber-ext-down 模块均已成功对接 Python 2 解释器，功能已彻底恢复。

五、避免环境冲突的长期建议

在 Linux 生产环境中，直接覆盖 /usr/bin/python 属于典型的高风险操作。不仅 yum，系统底层的防火墙配置工具 firewall-cmd 以及其他自动化脚本同样可能依赖系统自带的 Python 2 环境。

为了在未来彻底避免类似问题，推荐遵循以下运维准则：

保留默认软链接：始终让 /usr/bin/python 指向系统的原生版本，不要手动将其强行重指向 Python 3。
使用专用命令名：调用 Python 3 时，明确使用 python3 和 pip3 命令，也可以在个人用户的 ~/.bashrc 中添加个人别名，而不影响系统全局环境。
使用虚拟环境：项目开发应通过 python3 -m venv <env_dir> 创建独立的隔离虚拟环境，所有第三方包均在虚拟环境中安装，不污染宿主机系统。