在AWS RHEL 7.5部署ASP.NET Core 2.2 API时systemd服务启动失败求助

你遇到的退出码145，本质上是进程无法访问所需的文件或目录，权限不足导致的启动失败。结合你的systemd配置和部署环境，我整理了几个关键的排查和修复步骤：

1. 核心问题：apache用户的目录权限不足 #

你的服务配置里指定了User=apache，但程序的工作目录和dll文件都放在/home/ec2-user/webapi下——这个目录默认是ec2-user用户的私有目录，apache用户没有访问权限，这是最可能的原因。

修复方式（二选一，推荐第二种更安全）： #

• 快速测试：给其他用户开放目录的读和执行权限

  sudo chmod -R o+rx /home/ec2-user/webapi
  

• 更安全的权限配置：把apache用户加入ec2-user用户组，然后开放组权限

  sudo usermod -aG ec2-user apache
  sudo chmod -R g+rx /home/ec2-user/webapi
  

配置完成后，重新加载systemd并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart kestrel-mytest.service

2. 手动验证程序的可执行性 #

为了确认是权限问题，你可以切换到apache用户，手动尝试启动程序，看具体报错：

sudo su - apache
cd /home/ec2-user/webapi
dotnet prototypes.dll

如果这里弹出"权限被拒绝"或者找不到文件的提示，就坐实了权限问题；如果是其他报错（比如缺少.NET Runtime），再针对性解决。

3. 查看详细日志定位问题 #

用journalctl查看服务的实时日志，能获取dotnet启动时的具体错误信息，比systemctl status更详细：

sudo journalctl -u kestrel-mytest.service -f

这个命令会实时输出服务的日志，你能看到启动失败的具体原因，比如文件访问被拒、配置文件缺失等。

额外测试建议 #

如果权限调整后还是不行，可以临时把systemd配置里的User=apache改成User=ec2-user，然后重启服务测试。如果改成ec2-user后服务能正常启动，就说明核心问题确实是apache用户的权限不足。

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