【独立开发日记 004】一次令人窒息的 Debug：当麒麟系统的「安全」成为你的敌人

📋 项目背景：开发不难，维护才是噩梦

这是一个工业视觉的外包项目：通过 Python + OpenCV 连接海康威视摄像头的 RTSP 视频流，进行实时圆圈检测。听起来不复杂对吧？

项目本身的开发确实很快——核心功能就是读视频流、跑 YOLO 检测、画框、推送 MQTT。代码写完，本地测试通过，信心满满地交付。

然后，噩梦开始了。后期的部署调试和问题排查，花的时间比开发多得多。所谓**"做项目 1 天，维护 10 天"**虽然夸张，但真实反映了外包项目的痛点。

客户现场是某政企单位的实验室，用的是银河麒麟系统（国产信创电脑）。实验室有两台机器，我们称之为 2 号机和 3 号机。代码在 3 号机上跑得飞起，部署到 2 号机后，直接躺平。

报错信息：

端口554测试: 关闭
错误码: 11 (EAGAIN - Resource temporarily unavailable)

诡异的是：

• 🌐 浏览器能访问摄像头 Web 管理界面
• 🔌 Bash 测试端口 554 是通的
• 🐍 Python socket 测试端口 554 是不通的

同样的代码，同样的麒麟系统，一台能跑一台不能跑。这剧本，怕不是系统在整我。

🔍 排查过程

第一层地狱：网络？防火墙？

常规排查三连：

ping 10.30.105.234          # ✅ 通
nc -zv 10.30.105.234 554    # ✅ 通
sudo systemctl status firewalld  # inactive

网络没问题，防火墙关着的。那为什么 Python 连不上？

第二层地狱：kysec —— 麒麟的「贴心」安全管家

让现场工人跑诊断脚本，Python 测试时出现了神秘报错：

Fatal Python error: config_parse_cmdline: Permission denied by kysec
Python runtime state: preinitialized

kysec 是什么鬼？

原来是银河麒麟系统自研的强制访问控制模块，类似 SELinux，但比 SELinux 更"智能"——它会静默阻止它认为"不安全"的应用程序运行，包括 Python。

解决方案：打开「安全中心」→「应用保护」→ 把「应用程序执行控制」和「应用防护控制」都关掉。

🤦‍♂️ 吐槽：一个操作系统，默认把 Python 当成不安全程序拦截，你是认真的吗？作为开发者常用的语言，居然默认拦截？

第三层地狱：PyTorch MKL —— Intel 的「性能优化」反噬

关掉 kysec 后，Python 能跑了。但诡异的事情又来了。

我写了一个逐步导入测试脚本，结果发现：

# 初始状态
import socket
s = socket.socket()
r = s.connect_ex(('10.30.105.234', 554))
print(r)  # 输出 0，通！
 
# 导入 torch 后
import torch
s = socket.socket()
r = s.connect_ex(('10.30.105.234', 554))
print(r)  # 输出 11，不通！

import torch 之后，socket 就废了！

一番排查后发现，2 号机是 x86 架构（海光 Hygon C86），PyTorch 默认使用了 Intel MKL (Math Kernel Library) 加速数学运算。MKL 在初始化时做了一些骚操作，直接影响了后续的 socket 系统调用。

而 3 号机是 ARM 架构（飞腾 Phytium D2000），MKL 不支持 ARM，所以用的是 OpenBLAS，完全没这个问题。

📊 两台机器对比

🛠️ 解决方案

问题一：kysec 拦截

打开麒麟的「安全中心」→「应用保护」：

• 「应用程序执行控制」→ 选择「关闭」
• 「应用防护控制」→ 选择「关闭」

问题二：PyTorch MKL

安装 CPU-only 版本的 PyTorch（不含 MKL）：

# 卸载现有版本
pip3 uninstall torch torchvision -y
 
# 安装 CPU-only 版本
pip3 install torch torchvision --index-url https://download.pytorch.org/whl/cpu

如果内网无法访问外网，需要手动下载 wheel 文件：

• torch-2.2.0+cpu-cp38-cp38-linux_x86_64.whl
• torchvision-0.17.0+cpu-cp38-cp38-linux_x86_64.whl

🎯 技术总结

这次 Debug 花了我整整一个下午，远程指导现场工人，来回发截图、跑脚本。最后发现问题居然是：

1. 操作系统默认拦截 Python —— 作为一个开发者常用的语言，你居然默认拦截？
2. Intel MKL 搞破坏 —— 这个锅 Intel 要背，但国产系统作为"信创"产品，在兼容性测试上是不是应该更严格一点？

我整理了一套诊断脚本，以后再遇到类似问题，一键定位：

# Shell 诊断（检测网络、kysec、防火墙）
sudo sh diagnose.sh
 
# Python 诊断（检测模块导入、MKL 问题）
sudo python3 diagnose.py

💭 外包项目的深度思考

痛点一：客户现场环境 ≠ 开发环境

这是外包项目最大的坑。你在自己电脑上测试一切正常，到了客户那里就各种报错。

这次踩坑的根本原因：

• 我的开发机是 Ubuntu + Intel CPU
• 客户 3 号机是麒麟 + ARM（飞腾）
• 客户 2 号机是麒麟 + x86（海光）

三种完全不同的环境，PyTorch 的底层依赖（BLAS 库）都不一样。ARM 用 OpenBLAS，x86 用 MKL，而 MKL 有 bug 会影响 socket。

以后怎么避免？

1. 要求客户提供完整的系统信息（CPU 架构、OS 版本、已安装的 Python 版本）
2. 准备多套安装包（ARM 版、x86 版、CPU-only 版）
3. 写诊断脚本而不是让客户口述报错

痛点二：客户不懂技术，无法远程

政企项目往往涉及内网环境，无法远程连接。你只能通过微信指导现场人员操作。

这次的沟通链路是这样的：

我 → 微信发命令 → 客户 → 找现场工人 → 工人执行 → 拍照发回 → 我分析

一个来回至少 10 分钟。一个下午就这样过去了。

解决方案：

1. 写傻瓜式脚本——不要让客户敲命令，给他一个 一键诊断.sh，双击就能跑
2. 脚本输出要清晰——用中文、用 emoji、用分隔线，让截图一目了然
3. 准备好所有可能的修复方案——不要等问题定位了再想解决方案，提前把 wheel 包、配置脚本都准备好

痛点三：维护成本远超预期

外包项目最可怕的不是开发，是维护。

这个项目我报价的时候，预估工时是 2 天。实际开发确实很快完成了。但后续的部署、调试、现场问题排查，零零散散加起来花的时间远超开发本身——这就是所谓"做项目 1 天，维护 10 天"的由来（当然是夸张说法，但能体会那种心累）。

而且这些维护时间是碎片化的——客户可能任何时候发消息说"又不行了"，你得放下手头的事情去处理。

以后怎么定价？

1. 开发费 + 部署费 + 维护费要分开报价
2. 维护期要明确——比如交付后 1 个月内免费维护，超出按次收费
3. 远程支持 vs 现场支持价格不同——现场支持要加差旅费
4. 信创项目加价——国产系统的兼容性问题会多花 2-3 倍时间

痛点四：怎么筛选外包项目？

经过这次，我总结了几个接单红旗🚩：

绿旗✅：

• ✅ 客户有技术人员能配合调试
• ✅ 可以提供远程访问环境
• ✅ 需求明确，有文档
• ✅ 愿意为维护单独付费

🎤 吐槽时间：信创电脑的现状

银河麒麟作为国产操作系统的扛把子，在政企市场确实有不可替代的地位。但如果你的目标用户包括开发者，那这种「安全优先、体验靠后」的设计理念，真的需要反思。

一个好的操作系统应该是：让用户无感知地安全，而不是让用户感知不到自己被保护了什么。

国产 CPU（飞腾、海光、龙芯）+ 国产 OS（麒麟、统信）的组合，在政企市场是刚需。但生态还是太弱了：

• PyPI 上很多包没有 ARM wheel
• CUDA 在国产 GPU 上不能用
• 各种底层库的兼容性问题层出不穷

作为开发者，我支持信创的初衷，但希望厂商能多考虑下开发者体验。不要让"安全"成为阻碍生产力的借口。

📝 写在最后

踩过的坑都是经验。这次 Debug 虽然痛苦，但让我学到了：

1. 永远不要假设客户环境和你一样
2. 诊断脚本是远程支持的救命稻草
3. 外包项目的报价要包含维护成本
4. 信创项目要加风险溢价

希望这篇文章能帮到同样在信创适配路上踩坑的朋友们，也希望对正在考虑接外包的独立开发者有所启发。

#麒麟 #KylinOS #信创 #Debug #PyTorch #MKL #外包 #独立开发