* 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).