手动执行Puma启动命令无报错，作为systemd服务启动失败报203/EXEC

systemd抛出的 status=203/EXEC 没有复杂含义，指systemd在尝试启动主进程的最早期阶段，就无法执行 ExecStart 字段指定的可执行程序，流程在fork/exec环节直接终止，根本不会进入到Puma本身的代码加载、配置解析环节。
你手动在终端执行相同命令能成功，完全不代表systemd环境下能跑通——两者的运行上下文差异极大：手动终端是带完整用户登录态、shell初始化、环境变量加载的运行环境，而systemd启动服务是无shell的裸运行环境，两者权限、工作目录、文件读权限的默认配置完全不同。

按问题出现概率从高到低依次检查：

• 补全服务的基础运行参数
  这类报错最高发的原因，是puma.service文件没有指定运行用户和工作目录：systemd默认会用root身份从根目录启动进程，这种场景下很可能因为权限隔离，无法读取centos用户家目录下rvm的可执行文件，直接触发203错误。
  需要在service文件的[Service]段补充两行核心配置：

  User=centos
  Group=centos
  WorkingDirectory=/home/centos/app
  

• 验证ExecStart路径的有效性
  RVM安装路径下的bundle可执行文件很多是软链，手动登录态下能通过环境变量解析到正确目标，但systemd不会加载RVM的环境变量，一旦软链目标路径失效、或者跨软链的权限不对，就会直接执行失败。
  验证方法：切到centos用户执行 ls -l /home/centos/.rvm/rubies/ruby-3.0.0/bin/bundle，顺着输出的软链指向，逐段确认目标文件存在、有可执行权限，没有断链。
• 规避bundle exec的环境依赖
  systemd执行ExecStart命令时不会通过shell做路径解析，bundle exec puma本质是让bundle程序去查找应用目录下的puma可执行文件，一旦工作目录不对、或者gem路径在无shell环境下解析不到，就会出现执行失败。
  可以直接把ExecStart改成Puma本身的绝对路径，绕开bundle的路径解析逻辑：先通过命令 bundle info puma 找到puma的安装路径，再把ExecStart替换为puma二进制的完整绝对路径，比如：

  ExecStart=/home/centos/.rvm/gems/ruby-3.0.0/gems/puma-5.2.1/bin/puma -C /home/centos/app/config/puma.rb
  

• 重载systemd配置
  所有修改过的service文件，必须执行 systemctl daemon-reload 让systemd重新加载配置，否则服务启动时还是会用旧的配置参数，修改完全不生效。

[Unit]
Description=Puma HTTP Server
After=network.target

[Service]
Type=simple
User=centos
Group=centos
WorkingDirectory=/home/centos/app
ExecStart=/home/centos/.rvm/rubies/ruby-3.0.0/bin/bundle exec puma -C /home/centos/app/config/puma.rb
Restart=always

[Install]
WantedBy=multi-user.target

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