树莓派系统将.NET 6独立构建程序作为服务启动遇权限异常求助

核心原因分析 #

/proc/1是系统init进程（树莓派上即systemd）的proc目录，普通用户pi本身就没有权限访问其task/fdinfo子目录。手动运行程序时正常，说明程序在交互式会话环境下不会触发对该路径的访问，而systemd服务环境下触发了非预期的路径读取操作。

排查步骤 #

1. 定位触发访问的代码或组件 #

• 检查程序代码中是否存在直接读取/proc/1/task/fdinfo的逻辑，或是通过进程监控、系统信息采集类的第三方库间接触发了该访问。
• 使用strace跟踪服务启动时的系统调用，明确是哪一步触发了权限错误：

  sudo strace -f -e openat systemctl start kiai.service
  

  输出中会显示进程尝试打开/proc/1/task/fdinfo的调用栈，帮你定位问题源头。

2. 验证权限环境差异 #

临时修改systemd配置，用root用户启动服务测试：

[Service]
Type=simple
User=root
ExecStart=/home/pi/kiai/Kiai

如果服务能正常启动，说明确实是普通用户pi的权限不足以访问目标路径，后续需针对性调整程序或服务配置。

解决办法 #

方案1：修正程序路径访问逻辑 #

如果是代码或依赖库误访问了/proc/1，将其替换为当前进程的proc路径/proc/self（系统会自动解析为当前进程的proc目录），比如把/proc/1/task/fdinfo改成/proc/self/task/fdinfo，避免硬编码访问init进程的资源。

方案2：调整systemd服务配置 #

• 添加工作目录：确保服务运行时的工作目录与手动执行时一致，避免路径解析错误：

  [Service]
  Type=simple
  User=pi
  WorkingDirectory=/home/pi/kiai
  ExecStart=/home/pi/kiai/Kiai
  

• 放宽proc访问限制（谨慎使用）：如果程序确实需要访问系统进程信息，可在service段添加：

  ProtectProc=invisible
  

  该配置允许普通用户查看自身进程以外的proc信息，但会降低系统安全性，仅在必要时使用。

方案3：排查环境变量差异 #

手动运行时的交互式环境变量与systemd服务环境可能存在差异，可尝试继承用户的环境变量：

[Service]
Type=simple
User=pi
WorkingDirectory=/home/pi/kiai
EnvironmentFile=/home/pi/.bashrc
ExecStart=/home/pi/kiai/Kiai

注意：.bashrc中的部分命令可能不适合非交互式环境，需提前清理无关内容。

内容的提问来源于stack exchange，提问作者Dachi