According to the runsv man page:

If the directory service/log exists, runsv creates a pipe, redirects service/run's and service/finish's standard output to the pipe, switches to the directory service/log and starts ./run script. The standard input of the log service is redirected to read from the pipe.

Obviously, runsv only redirects service's standard output, but not standard error output, to svlogd standard input. My question is: why? Of course I want to log my unit's standard error output; why do I have to pay extra attention to adding exec 2>&1 to the beginning of each unit file?



Actually, you don't.

runsv takes this behaviour from svscan in the original Bernstein daemontools, which did the same. Almost everyone else has copied it. Bruce Guenter's svscan from daemontools-encore, Laurent Bercot's s6-svscan from s6, and Wayne Marshall's perpd from perp all do likewise.

Even Adam Sampson's svscan from freedt connects only standard output, despite calling the file descriptor err in the code. ☺

Noticing how extensively exec 2>&1 and fdmove -c 2 1 had become the norm, and observing that some programming languages explicitly define a standard log stream that ends up being file descriptor 2 (e.g. std::clog in C++), I made service-manager in the nosh toolset connect both standard output and standard error to the pipe when plumbing services together.

Further reading

  • Thanks for answer! Do you have any explanation why daemontools' original behaviour was to only redirect stdout but not stderr? Because that's what I'm interested in in the first place. – David Feb 28 '18 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.