supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* s6-rc how to log oneshot services
@ 2023-03-07 10:45 Daniel Barlow
  2023-03-07 11:53 ` Alex Kiernan
  2023-03-07 17:17 ` Carlos Eduardo
  0 siblings, 2 replies; 5+ messages in thread
From: Daniel Barlow @ 2023-03-07 10:45 UTC (permalink / raw)
  To: supervision


Hi all

I've adopted s6 and s6-rc for a small distro that's targeted at
consumer wifi routers and similar low-powered devices (same target
devices as openwrt) and so far I am appreciating the consistency and the
warm fuzzies that I get from having a supervision tree (and simple
readiness checks!)  instead of a folder full of pid files that may or
may not correspond with what's actually running.

My question is: how should I handle logging for oneshot services? I
have oneshots doing things that might fail, like configuring network
interfaces or inserting modules, and I'd like those failure messages to
go somewhere useful as the longrun messages do. If I just add
a logging service to a oneshot with producer-for/consumer-for I get

s6-rc-compile: fatal: longrun wlan.module-log declares a producer wlan.module of type oneshot

so I guess that's not the answer ...

What am I missing? I guess I could convert them into longruns that do
the "up" actions then call pause(2), but that seems a bit of a 
... non-traditional approach?


-dan








^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: s6-rc how to log oneshot services
  2023-03-07 10:45 s6-rc how to log oneshot services Daniel Barlow
@ 2023-03-07 11:53 ` Alex Kiernan
  2023-03-07 15:06   ` Laurent Bercot
  2023-03-07 17:17 ` Carlos Eduardo
  1 sibling, 1 reply; 5+ messages in thread
From: Alex Kiernan @ 2023-03-07 11:53 UTC (permalink / raw)
  To: Daniel Barlow; +Cc: supervision

On Tue, Mar 7, 2023 at 10:45 AM Daniel Barlow <dan@telent.net> wrote:
>
>
> Hi all
>
> I've adopted s6 and s6-rc for a small distro that's targeted at
> consumer wifi routers and similar low-powered devices (same target
> devices as openwrt) and so far I am appreciating the consistency and the
> warm fuzzies that I get from having a supervision tree (and simple
> readiness checks!)  instead of a folder full of pid files that may or
> may not correspond with what's actually running.
>

We're very similar... my target has a decent amount of compute, but
still an embedded device with constrained RAM and flash.

> My question is: how should I handle logging for oneshot services? I
> have oneshots doing things that might fail, like configuring network
> interfaces or inserting modules, and I'd like those failure messages to
> go somewhere useful as the longrun messages do. If I just add
> a logging service to a oneshot with producer-for/consumer-for I get
>
> s6-rc-compile: fatal: longrun wlan.module-log declares a producer wlan.module of type oneshot
>
> so I guess that's not the answer ...
>
> What am I missing? I guess I could convert them into longruns that do
> the "up" actions then call pause(2), but that seems a bit of a
> ... non-traditional approach?
>

Interested in the right answer - right now we just have an icky hack
so it just goes to uncaught-logs...

redirfd -w 1 /run/service/s6-svscan-log/fifo

I've not actually checked since we converted PID1 to s6-linux-init if
we still need that - I suspect we may not.

-- 
Alex Kiernan

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: s6-rc how to log oneshot services
  2023-03-07 11:53 ` Alex Kiernan
@ 2023-03-07 15:06   ` Laurent Bercot
  0 siblings, 0 replies; 5+ messages in thread
From: Laurent Bercot @ 2023-03-07 15:06 UTC (permalink / raw)
  To: supervision


  The default stderr for oneshot services is the default stderr of the
supervision tree you're running s6-rc with.
  So, if you're using s6-linux-init, stderr for oneshot services goes
directly to the catch-all logger and you don't need the redirection.

  If you want your oneshots to log to a different place, you need to
redirect the oneshot's stderr to where you want. Since oneshots are,
by definition, only run once, it's generally not necessary to have a
logger process for them; you can redirect to a file (but be careful
of concurrently running oneshots if you have several oneshots logging
to the same file!)

  You can send these logs to a logger process as well, but you cannot
use s6-rc's pipeline feature for that; you'll need to declare a fifo
manually, have a longrun service reading from that fifo, and have your
oneshot depend on that longrun and redirect its stderr to the fifo.
It's probably more trouble than it's worth.

--
  Laurent


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: s6-rc how to log oneshot services
  2023-03-07 10:45 s6-rc how to log oneshot services Daniel Barlow
  2023-03-07 11:53 ` Alex Kiernan
@ 2023-03-07 17:17 ` Carlos Eduardo
  2023-03-07 19:00   ` Laurent Bercot
  1 sibling, 1 reply; 5+ messages in thread
From: Carlos Eduardo @ 2023-03-07 17:17 UTC (permalink / raw)
  To: Daniel Barlow; +Cc: supervision

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

Artix Linux achieves this with

pipeline -dw { s6-log ... } actual-oneshot

Not ideal due to the lack of supervision for s6-log, but it works.

Em ter., 7 de mar. de 2023 08:12, Daniel Barlow <dan@telent.net> escreveu:

>
> Hi all
>
> I've adopted s6 and s6-rc for a small distro that's targeted at
> consumer wifi routers and similar low-powered devices (same target
> devices as openwrt) and so far I am appreciating the consistency and the
> warm fuzzies that I get from having a supervision tree (and simple
> readiness checks!)  instead of a folder full of pid files that may or
> may not correspond with what's actually running.
>
> My question is: how should I handle logging for oneshot services? I
> have oneshots doing things that might fail, like configuring network
> interfaces or inserting modules, and I'd like those failure messages to
> go somewhere useful as the longrun messages do. If I just add
> a logging service to a oneshot with producer-for/consumer-for I get
>
> s6-rc-compile: fatal: longrun wlan.module-log declares a producer
> wlan.module of type oneshot
>
> so I guess that's not the answer ...
>
> What am I missing? I guess I could convert them into longruns that do
> the "up" actions then call pause(2), but that seems a bit of a
> ... non-traditional approach?
>
>
> -dan
>
>
>
>
>
>
>
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: s6-rc how to log oneshot services
  2023-03-07 17:17 ` Carlos Eduardo
@ 2023-03-07 19:00   ` Laurent Bercot
  0 siblings, 0 replies; 5+ messages in thread
From: Laurent Bercot @ 2023-03-07 19:00 UTC (permalink / raw)
  To: Carlos Eduardo, Daniel Barlow; +Cc: supervision

>Artix Linux achieves this with
>
>pipeline -dw { s6-log ... } actual-oneshot
>
>Not ideal due to the lack of supervision for s6-log, but it works.

  Yes, it works. The lack of supervision doesn't matter here because
the s6-log is short-lived: it will die when actual-oneshot exits. The
main drawback here is that it's overengineered: chances are that
actual-oneshot is not going to write enough data to trigger a rotation,
so directly appending to a file would be simpler and faster.

  Additionally, the -d option to pipeline isn't necessary: unless
actual-oneshot does very suspicious things, it shouldn't notice it
has a child (which will outlive it by a few microseconds).

--
  Laurent


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-03-07 19:00 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-07 10:45 s6-rc how to log oneshot services Daniel Barlow
2023-03-07 11:53 ` Alex Kiernan
2023-03-07 15:06   ` Laurent Bercot
2023-03-07 17:17 ` Carlos Eduardo
2023-03-07 19:00   ` Laurent Bercot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).