为何runsv未重定向标准错误输出？需记录服务stderr日志

Great question! Let's break this down into two clear parts: the design reasoning behind runsv's behavior, and practical ways to capture your service's stderr output.

Design Rationale: Why stdout only? #

This choice ties directly to Unix/Linux's core conventions for standard streams:

• stdout is meant for regular, structured output (like transaction logs, status updates) that's intended for persistent logging or further processing.
• stderr is reserved for error messages, warnings, and diagnostic info—content that might need immediate attention, separate analysis, or even different handling entirely.

runsv's design prioritizes flexibility over enforcing a default. By not automatically redirecting stderr, it avoids making assumptions about your workflow:

• You might want to send stderr to a dedicated log file for easier debugging.
• You could pipe it to a monitoring tool instead of svlogd.
• In rare cases, you might even need to suppress stderr temporarily.

This hands-off approach lets you tailor logging to your specific needs rather than forcing a one-size-fits-all setup.

How to Capture Stderr with runsv #

If you want to include stderr in your svlogd-managed logs (or handle it separately), here are the most reliable methods:

1. Merge stderr into stdout (simplest approach) #

Modify your service/run script to redirect stderr to stdout before starting your service. This ensures both streams flow through the pipe runsv feeds to svlogd.

Example run script:

#!/bin/sh
# Redirect stderr to stdout so both streams go to svlogd
exec 2>&1
# Replace the shell with your service process (ensures signals are handled correctly)
exec /path/to/your/service --your-flags

The exec command is critical here—it replaces the shell process with your service, so signals (like those from sv stop) are delivered directly to your app instead of being swallowed by the shell.

2. Log stderr to a separate file #

If you want to keep stderr logs isolated, redirect it to a dedicated file in your service/run script:

#!/bin/sh
# Keep stdout going to runsv's pipe, send stderr to a separate log
exec 2>>/var/log/your-service/stderr.log
# Start your service
exec /path/to/your/service --your-flags

You can add log rotation for this file separately, or even set up a secondary runsv service to manage it if needed.

3. Split logs with multilog (advanced) #

For granular control, use multilog (part of the daemontools suite runsv belongs to) to split stdout and stderr into distinct log directories. Update your service/run script:

#!/bin/sh
# Use multilog to route stdout and stderr to separate log paths
exec /usr/bin/multilog t ./log/stdout ./log/stderr 2>&1

Then, you can configure your service/log/run script to target either directory, or set up separate log services for each stream.

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