supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Laurent Bercot" <ska-supervision@skarnet.org>
To: supervision <supervision@list.skarnet.org>
Subject: Re: s6-svscan catch-all logger service
Date: Fri, 26 Apr 2019 09:45:38 +0000	[thread overview]
Message-ID: <emec953ac4-0c5c-4122-81e3-965aaf8d4a56@elzian> (raw)
In-Reply-To: <42655961556240486@myt5-cf6d29327892.qloud-c.yandex.net>

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


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

You need to have execline installed to run s6 anyway. And again,
you don't have to do the required effort yourself, it has already
been made for you and you can just reuse the existing solutions.


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

Yes, from what I can see in the code, it works when the logdir is
in the scandir, and it seems to be the intended use. But it also
*appears to work* when the logdir is not in the scandir, and that
is not good. We're talking pid 1 here. It needs to be *airtight*.


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

Running a supervision tree requires a rw fs anyway, so that's not a
problem at all.


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

Distributions do. They don't want to spend hours of effort looking
for places where sysvinit assumptions are made and fixing them, and
that is understandable. Even systemd came with compatibility
halt/poweroff/reboot/shutdown binaries, to make it easier for
distributions to switch.

--
Laurent

  reply	other threads:[~2019-04-26  9:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-25 18:09 special s6-svscan/perp(d) catch-all logger service option Jeff
2019-04-25 23:11 ` Laurent Bercot
2019-04-26  1:01   ` s6-svscan catch-all logger service Jeff
2019-04-26  9:45     ` Laurent Bercot [this message]
2019-04-26 16:29       ` Jeff
2019-04-26 18:45         ` Laurent Bercot
2019-04-26 19:23           ` Jeff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=emec953ac4-0c5c-4122-81e3-965aaf8d4a56@elzian \
    --to=ska-supervision@skarnet.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).