>I'm not completely sure about s6, but runsv (from runit) hands only the
>stdout of the ./run script to the logger, and passes the stderr out of
>it's own stderr.
All daemontools-inspired supervision suites, including s6, follow that
model, so yes, your runit example can be directly applied to s6.
Generally speaking, supervision suites only provide integrated support
(i.e. a pipe that is already created and maintained by the supervision
tree) for one output channel, and if a service needs other output
channels then it's of course possible but the plumbing must be done
manually.
In Carl's case: in order to have foo's stdout logged by a dedicated
logger, and foo's stderr by *another* dedicated logger, then you can
do something like the following:
- If /service/foo is your service directory for foo, then you declare
your service directory for foo's stdout in /service/foo/log.
- mkfifo -m 0600 /service/foo/stderr-pipe
- In /service/foo/run, redirect stderr to stderr-pipe
- Write a separate service directory, say /service/foo-stderr-log,
with a run script that redirects its stdin from /service/foo/stderr-pipe
and execs into s6-log.
This should do what you want, with a small caveat: if the process for
foo-stderr-log dies, then you'll need to restart foo in order to get
any further logs, because the pipe has been broken and isn't maintained
by the supervision tree like the pipe to foo/log is.
The way to prevent this is to use a fd-holder, and s6 provides tools
for that, but it's the next level of complexity.
Historically, the vast majority of daemons have only needed one output
channel, and that is why supervision suites address the common case but
offer no help otherwise; unfortunately, certain web servers buck the
trend and need several output channels (which is not a bad idea per se,
it's just that the tooling to handle it in a user-friendly way is not
there yet), so for now the way to address it is still to whip out the
hammer and screwdriver.
s6-rc wouldn't help you in that case, because its funnel model still
only supports one consumer per producer, and extra output channels have
to be set up manually as well.
The nginx/apache case is something that comes up with some regularity,
either on this list or on the #s6 channel, so I should try and write
some tools that make it easier to automate. However, it is likely that
those tools would become part of s6-rc, not s6, because doing things in
a reliable way involves a fdholder, which requires some policy that
s6 does not provide but s6-rc does (and s6-rc already has all the
necessary infrastructure).
--
Laurent
Received on Sat Jun 13 2020 - 12:42:59 UTC