From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no
	version=3.4.4
Received: (qmail 15938 invoked from network); 7 Mar 2023 10:45:40 -0000
Received: from alyss.skarnet.org (95.142.172.232)
  by inbox.vuxu.org with ESMTPUTF8; 7 Mar 2023 10:45:40 -0000
Received: (qmail 16285 invoked by uid 89); 7 Mar 2023 10:46:02 -0000
Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm
Sender: <supervision@list.skarnet.org>
Precedence: bulk
List-Post: <mailto:supervision@list.skarnet.org>
List-Help: <mailto:supervision-help@list.skarnet.org>
List-Unsubscribe: <mailto:supervision-unsubscribe@list.skarnet.org>
List-Subscribe: <mailto:supervision-subscribe@list.skarnet.org>
List-Id: <supervision.list.skarnet.org>
Received: (qmail 16278 invoked from network); 7 Mar 2023 10:46:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=telent.net; s=mail;
	t=1678185934; bh=xZDacIvWvSkMA96CJHFQQZX5lMOaF6x/IbLZvSrTw98=;
	h=From:To:Subject:Date;
	b=M8ctnkTfuZ9QH88GJTA0WRv51U0Dr+gSK8szPI21kdYw76QGXNPdM9cuvyaluEU5M
	 uTP/JsB+Wbw7Slb2Ae0O3SppVQvAbgZ4Pt/OR31BWna64WyOGBsp5d2yfohbR8SoNE
	 jF+fG+/Bj5i6Y7FV+K6tPLwhG5rfjbN8nw+4pkes=
From: Daniel Barlow <dan@telent.net>
To: supervision@list.skarnet.org
Subject: s6-rc how to log oneshot services
Date: Tue, 07 Mar 2023 10:45:30 +0000
Message-ID: <87edq0suut.fsf@telent.net>
MIME-Version: 1.0
Content-Type: text/plain


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