S6-log

S6-log

[billa chaitanya]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

Hi team,

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>


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


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

Thanks
Chaitanya

Re: S6-log

[Crest]

On 04.11.20 10:42, billa chaitanya wrote:
> Hi team,
>
> 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>

It does not go down, because the dependency is the other way around. The 
service requires its log service, but the log service doesn't require 
its service to start (it's just useless without it).

s6-rc -u change foo starts a service and all its dependencies (including 
its log service). s6-rc -d change bar stops all services depending on a 
service and the service. Stopping the log service stops the service as 
well. Starting the service starts the log service.

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

Oneshot services are started by the s6 oneshot runner. This long running 
service is required to start oneshots in a clean environment.

> 3) is there any command-line option we can provide to s6-log for stopping
> the running s6-log?
What problem are you trying to solve? s6-log shouldn't have deal with 
replacing an other s6-log process itself.

Re: S6-log

[Laurent Bercot]

>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