Re: S6-log

["Laurent Bercot" <ska-supervision@skarnet.org>]

>1) does the log service of a corresponding long run service goes down when
>the long run service is made down using some s6 commands? (like s6-rc -d
>change <long run service name>

  No, because as Crest says, a producer foo depends on a consumer 
foo-log,
not the other way around, so bringing up foo also forces foo-log to be
up, but bringing it down does not force foo-log to be down. (Bringing
down foo-log, however, forces foo to be down.)

  s6-rc provides you with a natural solution to this, though: in your
foo-log definition directory, you can define a "pipeline-name" file:
that will automatically create a bundle containing foo and foo-log,
named after the contents of pipeline-name. If you do, for instance:
   echo foo-pipeline > foo-log/pipeline-name
and recompile your database, then
   s6-rc -u change foo-pipeline
will always bring up foo *and* foo-log, and
   s6-rc -d change foo-pipeline
will always bring down foo *and* foo-log.


>2) Shall we use s6-log for one shot services too?

  s6-log is a long-lived process, designed to log the output from
long-lived process. It doesn't really make sense to use a dedicated
logger for a oneshot.

  What s6-rc does is that the output from all your oneshots is sent
to the catch-all logger, i.e. the place where the supervision tree
sends its output by default. If you are using a s6-linux-init
installation, or similar, chances are that this catch-all log is
itself handled by a s6-log process. Check your /run/uncaught-logs
directory.


>3) is there any command-line option we can provide to s6-log for stopping
>the running s6-log?

  To stop a running s6-log process, simply send it a SIGTERM. If the
s6-log process you want to stop is supervised, the command you want
is probably
   s6-svc -d /run/service/foo-log

  Be aware, though, that if you stop a logger without stopping the
corresponding service, funny things can happen when the logging pipe
fills up: depending on how the service is written, it may lose logs,
or it may hang, or it may die. You should probably never have to
stop a logging process without bringing down the entire pipeline that
leads to it.

--
  Laurent