SELinux拦截服务启动最典型表现是systemd报status=203/EXEC且服务failed，但无明确“Permission denied”；排查须按“确认→定位→修复”三步：先用getenforce/setenforce验证是否SELinux所致，再用ausearch/audit2why分析AVC日志定位拒绝项，最后针对文件标签、端口类型或布尔值错误精准修复。
SELinux 拦截服务启动时，最典型的表现是 systemd 报 status=203/EXEC、服务状态为 failed，但日志里找不到明确的“Permission denied”或文件路径错误——它不拦在权限层，而是在进程执行前就卡死。排查核心不是关 SELinux，而是确认它是否在拦、拦在哪、怎么精准放行。
第一步：确认 SELinux 是否正在生效并验证根因
先别改配置，用两步快速锁定问题：
- 运行
getenforce—— 若返回 Enforcing，说明策略正在强制拦截；若为 Permissive 或 Disabled，基本可排除 SELinux - 临时切宽容模式验证：
sudo setenforce 0，然后立即重启服务：sudo systemctl restart 服务名；若此时启动成功，几乎可以确定是 SELinux 拦截 - 验证完立刻恢复：
sudo setenforce 1，避免审计日志失效影响后续分析
第二步：查审计日志，定位具体被拒动作
拒绝记录不在 /var/log/messages 或 journalctl -u 服务名 里，必须查 /var/log/audit/audit.log：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 按进程名过滤最近的 AVC 拒绝：
sudo ausearch -m avc -c 服务进程名（如 mysqld、httpd、named） - 把原始日志转成可读解释：
sudo ausearch -m avc -c 服务进程名 | audit2why—— 它会直接告诉你缺哪条规则，比如 “Missing allow httpd_t var_log_t:file write” - 生成结构化诊断报告（需已安装 setroubleshoot）：
sudo sealert -a /var/log/audit/audit.log
第三步：根据常见拦截类型修复
90% 的问题集中在三类上下文错配，对应修复方式不同：
-
文件/脚本标签错误：服务启动脚本或二进制文件的安全上下文不对（如被误标为
user_home_t）。查标签：ls -Z /path/to/exec；修复：sudo semanage fcontext -a -t init_exec_t "/path/to/exec"，再sudo restorecon -v /path/to/exec -
端口类型不匹配：服务监听非标准端口（如 nginx 听 8080），但该端口未被标记为
http_port_t。查当前允许端口：sudo semanage port -l | grep http_port_t；添加：sudo semanage port -a -t http_port_t -p tcp 8080 -
布尔值未开启：服务需要额外能力（如访问网络、读取家目录）。查开关：
getsebool -a | grep 服务名；启用：sudo setsebool -P 服务名_can_network_connect on
第四步：慎用 audit2allow，优先走标准修复路径
audit2allow 能自动生成策略模块，但它绕过策略设计逻辑，容易埋下安全漏洞：
- 仅当上述三类修复都不适用、且确认行为合理时，才考虑：
sudo ausearch -m avc -c 服务进程名 | audit2allow -M mypolicy，再sudo semodule -i mypolicy.pp - 生产环境应避免直接导入自定义策略，优先使用
semanage和setsebool这类受控机制
