linux服务默认通过stderr（fd 2）输出错误，关键在于确保其不被关闭或重定向；systemd中通过standarderror=journal（默认）或append:/path捕获，手动启动可用2>/file重定向，并需验证fd 2指向正确目标。
Linux 系统服务将日志输出到标准错误流（stderr），关键不是“配置服务去输出”，而是确保服务进程本身把错误信息写到 fd 2（stderr），然后由 systemd 或启动方式决定是否捕获、重定向或转发它。大多数现代服务默认就使用 stderr 输出错误——你真正要做的，是让系统正确接收并保存这些输出。
明确 stderr 是默认错误通道
服务程序（如用 C/Python/Go 编写的守护进程）在出错时调用 fprintf(stderr, ...)、syslog(LOG_ERR, ...) 或直接 write(2, ...)，本质上就是往文件描述符 2 写数据。只要不主动关闭或重定向它，stderr 就保持可用。
⚠️注意：很多守护进程（如 nginx、redis）启动时会主动关闭 stdin/stdout/stderr；若没做日志适配，错误可能直接丢失。
systemd 服务中启用 stderr 捕获
如果你用 systemd 管理服务（推荐），在 .service 文件的 [Service] 段配置：
-
StandardError=journal（默认值）→ 错误自动进入 journald，可用journalctl -u xxx.service -p err查看 -
StandardError=append:/var/log/xxx.err.log→ 直接追加写入指定文件（需确保目录存在、权限可写） -
StandardError=console→ 输出到控制台（仅调试时用，生产环境不适用）
✅ 示例（/etc/systemd/system/myapp.service）：
[Service] Type=simple ExecStart=/usr/local/bin/myapp --config /etc/myapp.conf StandardError=append:/var/log/myapp.err.log Restart=on-failure
然后执行：
sudo systemctl daemon-reload sudo systemctl restart myapp.service
手动启动时显式重定向 stderr
适用于调试或非 systemd 场景：
# 后台运行，并把 stderr 单独存入文件 /usr/local/bin/myapp 2>/var/log/myapp.err.log & # 同时记录 stdout 和 stderr（推荐用于临时排查） /usr/local/bin/myapp &> /var/log/myapp.all.log & # 只保留错误，正常输出丢弃 /usr/local/bin/myapp 2>/var/log/myapp.err.log >/dev/null &
验证 stderr 是否生效
-
查看进程打开的文件描述符：
sudo ls -l /proc/$(pidof myapp)/fd/2
正常应指向
anon_inode:[pts]（前台）、/var/log/...（重定向后）或socket:[...]（journal 模式）。 -
检查日志内容是否包含错误（比如故意触发一个错误）：
# 触发错误（如传无效参数） /usr/local/bin/myapp --invalid-flag 2>&1 | head -5
不推荐但常见误区
-
>& /dev/null或>/dev/null 2>&1：错误全丢，失去排错依据 - 仅依赖
stdout记录错误：很多程序只把错误打到stderr，stdout可能为空 - 忘记设置
Restart=和RestartSec=：服务崩溃后 stderr 日志可能来不及刷盘就终止
不复杂但容易忽略
