终端能启动网关，写进ExecStart却把管道当参数，怎样改成确定的启动方式

常规ExecStart不会自动经过shell，管道和重定向符可能只是传给程序的普通参数。先确认进程实际收到的argv，再把日志交给journal或显式选择shell，避免把终端命令原样粘贴进服务定义。

复现命令行与ExecStart解析差异

终端里的竖线能工作，是当前shell负责拆管道；systemd解析服务命令有自己的规则，不等于执行一整行交互命令。故障日志里出现未知参数tee或竖线时，应先还原参数序列，而不是怀疑网关版本缺少该选项。环境变量和引号也需要按服务管理器文档理解。

用argv打印器固定实际参数

附件用打印argv的假程序接收配置参数、竖线、tee和日志名，竖线真实出现在参数数组中；显式shell对照则把简单echo送入另一个程序。它验证的是直接启动与shell解释之间的区别，没有在机器上注册任何systemd服务，所以不能把这份输出称作服务启动验收。

服务日志中“未知参数”往往比启动命令文本更接近事实，因为它暴露应用真正收到的argv。先把参数打印器换到隔离实验中核对，再调整正式unit；不要让打印器输出完整环境变量或真实Key。脚本若承担启动职责，最后的exec还能减少中间shell对主进程身份的影响。

示例unit或排查命令：以下路径与服务名须按目标环境替换，本文没有注册或执行这些服务操作。

[Service]
ExecStart=/usr/local/bin/demo-gateway --config /etc/demo-gateway/demo.json
StandardOutput=journal
StandardError=journal

说明新版简写不套旧systemd

更确定的服务定义通常让ExecStart直接指向可执行文件，配置使用绝对路径，标准输出由journal接管。确实需要复杂预处理时，单独写受版本管理的启动脚本更容易核对退出码与信号传递。使用shell时不要忽略exec，否则主进程和停止信号的关系也可能改变。

适用范围：Python实际验证argv差异，systemd集成只在可用Linux用户级管理器验证；不改系统服务。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

运行run.py不需要systemd，它会启动打印参数的子进程和一个明确的shell对照。direct_argv里应包含竖线，shell_pipeline应只有demo。这个结果用于理解启动方式，不能拿来宣称unit已经安装成功；实际服务定义还应在目标版本上校验，并检查主进程、退出码与日志去向。

Python3.8以上及标准库即可。本题的启动参数全部是程序内合成输入，运行不会读取网关业务数据，也不会注册服务或定时任务。

python -B run.py

阅读输出时，先按case.json中的任务逐项核对systemd网关ExecStart管道，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（常规ExecStart不是shell命令，管道和重定向须显式shell；不使用latest中新加的简写语法。）。

继续阅读：网关交给systemd后找不到相对配置文件，怎样核对工作目录与绝对路径；shell的ulimit很高网关仍报too many open files，怎样核对服务进程实际限制；Docker发了SIGTERM服务却没收到，怎样检查启动脚本与PID1。