service-control启动失败，返回码RC=1

Question

问题描述：在Linux系统中启动自定义服务时，service-control脚本执行失败，返回码RC=1。该服务依赖于特定环境变量和配置文件路径，常见于部署后首次启动或升级后场景。经日志分析，/var/log/service-control.log提示“Failed to load configuration: No such file or directory”，但配置文件实际存在于指定路径。进一步排查发现，systemd服务单元中WorkingDirectory未正确设置，导致进程启动时工作目录错误，无法定位相对路径配置。此外，权限不足或SELinux策略限制也可能触发相同返回码。如何准确诊断并解决因运行上下文不一致导致的service-control启动失败（RC=1）问题？

Answer 1

一、问题背景与现象分析

在Linux系统中部署自定义服务时，常通过systemctl start my-service调用service-control脚本启动服务。然而，在部署或升级后首次启动过程中，频繁出现返回码RC=1的错误。

查看日志文件/var/log/service-control.log，发现关键错误信息为：

Failed to load configuration: No such file or directory

初步怀疑是配置文件缺失，但实际验证发现配置文件确已存在于预期路径（如/etc/myapp/config.yaml）。这表明问题并非源于文件丢失，而是运行上下文不一致导致的资源定位失败。

二、常见原因分类与排查路径

导致RC=1的潜在因素可归纳为以下三类：

1. 工作目录未正确设置：systemd默认以根目录或用户家目录作为工作目录，若服务依赖相对路径加载配置，则会查找失败。
2. 环境变量缺失：服务启动脚本依赖ENV_CONFIG_PATH等变量，但未在systemd单元中显式声明。
3. 权限与安全策略限制：包括文件权限不足、SELinux拒绝访问、AppArmor策略拦截等。

三、systemd服务单元配置深度解析

检查服务单元文件/etc/systemd/system/myapp.service内容：

[Unit]
Description=My Custom Application
After=network.target

[Service]
ExecStart=/opt/myapp/bin/service-control start
User=myapp
Group=myapp

[Install]
WantedBy=multi-user.target

上述配置存在明显缺陷：WorkingDirectory和EnvironmentFile均未设置，导致进程在/目录下运行且无必要环境变量。

四、修复方案与最佳实践

修正后的服务单元应包含如下关键字段：

配置项	作用说明	推荐值
WorkingDirectory	设定进程工作目录，确保相对路径解析正确	/opt/myapp
EnvironmentFile	加载外部环境变量文件	/etc/sysconfig/myapp
PermissionsStartOnly	允许在特定阶段执行需特权的操作	true
ProtectHome	控制对/home、/root、/run/user的访问	false（按需开启）
ReadWritePaths	明确授权可读写路径（SELinux友好）	/opt/myapp/conf /var/log/myapp

五、SELinux与权限问题诊断流程图

当排除路径与环境问题后，应进入安全策略排查阶段。以下是诊断流程：

graph TD
    A[服务启动失败 RC=1] --> B{检查audit.log}
    B -- 存在AVC拒绝 --> C[使用sealert -a /var/log/audit/audit.log]
    C --> D[识别缺失的SELinux规则]
    D --> E[生成并加载模块
checkmodule -M -m -o myapp.mod myapp.te
semodule_package -o myapp.pp -m myapp.mod
semodule -i myapp.pp]
    B -- 无AVC记录 --> F[检查文件权限]
    F --> G[确认服务用户对配置目录有读权限]
    G --> H[chown -R myapp:myapp /opt/myapp/conf]
    H --> I[chmod 644 /opt/myapp/conf/*]
    

六、自动化诊断脚本建议

为提升运维效率，可编写诊断脚本diagnose-service.sh：

#!/bin/bash
SERVICE_NAME="$1"
LOG_FILE="/var/log/service-control.log"

echo "=== Diagnosing $SERVICE_NAME ==="
systemctl is-active "$SERVICE_NAME" || echo "[!] Service not active"

journalctl -u "$SERVICE_NAME" --no-pager -n 50 | grep -i "failed\|error" > /tmp/diag.err

if grep -q "No such file" /tmp/diag.err; then
    echo "[*] Possible working directory misconfiguration"
    SYSTEMD_DIR=$(systemctl show "$SERVICE_NAME" | grep FragmentPath)
    echo "Systemd unit location: $SYSTEMD_DIR"
fi

if command -v seinfo > /dev/null; then
    grep "avc:.*denied" /var/log/audit/audit.log | tail -5 | while read line; do
        echo "[SECURITY] SELinux denial detected:"
        echo "         $line"
    done
fi

该脚本整合了服务状态、日志关键词、SELinux事件等多维度检测逻辑，适用于批量环境巡检。

七、持续集成中的预防措施

在CI/CD流水线中加入如下检查点可有效预防此类问题：

• 单元测试阶段验证service-control脚本在不同PWD下的行为一致性
• 部署前静态扫描systemd单元文件是否包含WorkingDirectory
• 使用lintian或自定义hook检查包内配置文件权限
• 在容器化环境中复现systemd上下文（如使用docker run --privileged调试）
• 集成OpenSCAP策略扫描，提前发现SELinux合规风险

通过构建“配置即代码”体系，将服务运行上下文标准化，从根本上规避因环境差异引发的RC=1故障。