Node.js 用 systemd 运行：服务账号、环境变量与重启策略
正式应用需要在管理员退出终端后继续运行，也要能被清楚地启动、停止和查看日志。systemd 适合管理单机上的常驻进程。本文以 Ubuntu 24.04 为例，应用使用仍受维护且已通过项目测试的 Node.js 版本，并已完成依赖安装。
先固定运行路径与服务账号
确认 Node.js 可执行文件的真实路径，以及应用入口、工作目录和配置来源。交互终端通过版本管理器找到的 node，不一定能被系统服务找到。服务文件应使用已经核实的绝对路径，避免依赖某位管理员的登录脚本。
准备专用普通账号，只允许它读取应用代码，并写入确实需要的上传、缓存或日志目录。不要因为端口或文件权限错误就让整个应用以 root 运行。本文假设 siteapp 账号已经存在，应用目录为 /srv/site/current，这些名称都需要按实际部署替换。
创建独立服务文件
确认 /etc/systemd/system/site.service 尚未被其他业务使用后，按实际路径创建配置：
[Unit]
Description=Site Node.js application
After=network.target
[Service]
Type=exec
User=siteapp
WorkingDirectory=/srv/site/current
ExecStart=/usr/bin/node /srv/site/current/server.js
Environment=NODE_ENV=production
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
[Install]
WantedBy=multi-user.target
应用应以前台方式运行，让 systemd 管理主进程，不要再在启动命令后加后台符号或重复套另一层常驻管理器。工作目录与执行环境的含义可查systemd.exec 手册。
配置中的环境变量只是示例，应用是否使用它取决于代码。敏感配置不应写在公开服务文件示例里，实际部署采用权限受控的配置或凭据机制。程序监听地址也应在应用配置中明确，不能假定写了服务文件就会自动限制公网访问。
检查后启动，再决定开机启用
在确认端口未被其他实例占用、准备接管现有进程后，逐条执行：
sudo systemd-analyze verify /etc/systemd/system/site.service
sudo systemctl daemon-reload
sudo systemctl start site
sudo systemctl status site --no-pager
sudo journalctl -u site -n 80 --no-pager
服务启动失败时，先根据日志区分账号不存在、工作目录错误、解释器路径错误或应用异常。不要重复启动多个手工进程抢占同一端口。确认本机与反向代理后的业务访问都正常，再执行 sudo systemctl enable site 安排开机启动。
重启策略不能替代健康检查
Restart=on-failure 可以在进程异常退出时安排重启，但进程仍存在却无法处理请求时，不一定会触发。还需要从应用入口监测可用性，并让程序正确处理依赖失败与退出信号。systemd.service 手册
如果日志显示持续退出和重启，先停止这一个服务并调查，不能靠缩短重启间隔解决。反复重启可能加重数据库连接和外部接口压力。修改服务文件后需要重新加载管理器配置；修改应用配置是否需要重启，则按应用的加载方式安排。
用可恢复发布方式验收
验证本机健康入口、外部域名、实际业务和日志，并在维护安排下确认停止、启动行为符合预期。服务状态显示 active，不代表所有请求都能成功；也不要把一次端口测试当作数据库和任务执行已经正常。
保留上一版本应用及服务配置。失败时先恢复匹配的程序和配置，再重新加载或启动；涉及数据库变化时必须先确认回退兼容。最后记录服务名称、账号、入口和日志查询方式，让接手的人能够管理这一个进程，而不是依赖某个仍开着的终端窗口。