From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2533 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jeff Newsgroups: gmane.comp.sysutils.supervision.general Subject: s6-svscan catch-all logger service Date: Fri, 26 Apr 2019 03:01:26 +0200 Message-ID: <42655961556240486@myt5-cf6d29327892.qloud-c.yandex.net> References: <48006661556215743@iva7-8175209a746b.qloud-c.yandex.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="243899"; mail-complaints-to="usenet@blaine.gmane.org" To: supervision Original-X-From: supervision-return-2123-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Apr 26 03:01:30 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hJpF4-0011MY-5D for gcsg-supervision@m.gmane.org; Fri, 26 Apr 2019 03:01:30 +0200 Original-Received: (qmail 29142 invoked by uid 89); 26 Apr 2019 01:01:55 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 29135 invoked from network); 26 Apr 2019 01:01:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1556240486; bh=EKZhq0J9KInCaZ/e0TsbmxYKVQpvTMlojkOOWQjgKqM=; h=References:Date:Message-Id:Subject:In-Reply-To:To:From; b=GslLXnzIrMUNiM51iE9Vi5yna8fuS/tRt4bW9MH4vVyKe2AHrt64XaVoK7g89nFV9 uqmNdCU5LtOGqgEObVIutmk/il3YpNrrZ/R0dw2PBFcXSNFSGfukjgWorPMuR4Ru9P E12mUTUNXW/RROCD4gwrmk1g0prjYBJBHEdUJsv8= Authentication-Results: mxback1o.mail.yandex.net; dkim=pass header.i=@yandex.com In-Reply-To: X-Mailer: Yamail [ http://yandex.ru ] 5.0 Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2533 Archived-At: 26.04.2019, 01:10, "Laurent Bercot" : > The bad news is that the way daemontools-encore's svscan manages > its catch-all logger is almost exactly the way I do it in my stage 1 > scripts, except it requires ad-hoc code in svscan. but this "ad-hoc code" is in C and does not require any execline tricks. for those to work you need execline installed too. that way daemontools-encore's svscan can easily get directly started and supervised by process #1 without any effort. i think this feature does not require too much "ad-hoc" C code in the svscan source. it is easy to do that in C while it becomes hard to impossible do write a shell script that does it (ok, in execline this seems to be possible, but you need that package installed then). > Additionally, the way daemontools-encore does it, the logdir may > or may not be in the scandir. really ? i always used a service subdir of the scandir and it worked very well. > If it is not in the scandir, it will > not be watched by svscan, and if both the supervise process and the > logger die, nothing will ever read the logpipe again and when the > kernel buffer fills up, your supervision tree will eventually freeze. pretty artificial counter example since noone will use a service dir outside the scandir. i do not know if this is even possible ... in any case doing so seems very odd to me and was probably not intended by the author. > and performing a little FIFO trickery at svscan start time in order see ? "a little trickery" is necessary here. > to redirect its stdout and stderr to a FIFO (that the catch-all > logger will read from). The differences in implementation is that > the logpipe is a FIFO, not an anonymous pipe, and it's held open by > the logger, not by svscan or supervise. using a fifo here is IMO not the best solution when using a simple pipe(2) would suffice since fifos need read-write access to fs they reside on. > You're saying that my implementation makes running s6-svscan under > sysvinit complex because you need 2 lines in /etc/inittab. that was just a general remark not specific to SysV, busybox or toybox init that applies to every process #1 (and also to init stage 1 when using s6-svscan as stage 2) > That is not true: you only need 1 inittab line, that runs a "mini-stage 1" > script that performs the FIFO trick (as well as any other early > preparation that you need) before executing s6-svscan. yes that works but introduces an extra step of indirection. and again this seems to require execline. it becomes more difficult doing so directly from -say- inittab or its actual equivalent for the given init system. > You're also saying that this implementation makes stage 1 scripts > difficult to write. That is true indeed. > I would also recommend you, or anyone interested in stage 1 script > creation, to do this sooner rather than later, because a new version > of s6-linux-init is going to be released in less than a week, i see. > and it will be significantly different, and more complex > (because more featureful, > with a focus on turnkey sysvinit compatibility who needs such compatibility anyway ? those who want/need it should run SysV init directly and start s6 per init script/inittab entry. > stage 1 will be a C program rather than an execline script nice ! that sounds really interesting to me. you have suprised and teased me definitely with this announcement. good luck.