From: "J. Neuschäfer via buildroot" <buildroot@buildroot.org>
To: Arnout Vandecappelle <arnout@mind.be>
Cc: "J. Neuschäfer" <j.neuschaefer@gmx.net>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH] system: Add option to maintain a supervision tree
Date: Thu, 18 Jul 2024 22:53:17 +0200 [thread overview]
Message-ID: <ZpmAvdJnGWB5T4DG@probook> (raw)
In-Reply-To: <0d66f3e0-cec6-487a-8bfa-880142420e52@mind.be>
On Sun, Jul 14, 2024 at 11:11:57PM +0200, Arnout Vandecappelle wrote:
> Hi J.,
>
> On 04/07/2024 21:00, J. Neuschäfer via buildroot wrote:
> > One of the major drawbacks of classic init/rc systems is that dead
> > daemons remain dead: Once started by the rc scripts, they are left to
> > look after themselves.
> >
> > A simple approach to keep them running reliably is to supervise them:
> > In a tree with PID 1 at its root, every process knows which children
> > ought to run under it, and it respawns them accordingly. This is the
> > supervision tree.
> >
> > Classic init already provides rudimentary supervision in the form of
> > inittab. This patch uses inittab to establish a more flexible
> > supervision tree based on runit's rvsvdir or s6's s6-svscan.
>
> We discussed this patch here at the Buildroot hackaton. Although we fully
> agree that having a supervisor is extremely useful, we also feel that this
> patch is very invasive for something that is relatively simple to implement
> at the moment. The only thing you need to do is to select the supervisor you
> want to use, and put a custom inittab in the filesystem overlay that starts
> the supervisor. Oh, and you probably also want a post-build script to remove
> everything in /etc/init.d for which you created a service instead - but that
> part isn't even handled by this patch.
>
> One of Buildroot's main principles is keeping it simple. Over the years,
> we've already collected way too much complexity. Therefore, we've decided to
> reject this patch.
Fair enough -- the particular design trade-offs can be a bit difficult
to see from the outside. For example (and this is not a reason to merge
my patch, just an explanation of my thought process), adding a custom
inittab requires knowing/copying the whole inittab, whereas the user of
this option would only need to know that they want a supervision tree,
which is from that perspective simpler.
>
> Regardless, thank you for your contributions!
Again, thank you for your thoughtful and friendly reviews :)
-- jn
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2024-07-18 20:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-04 19:00 [Buildroot] [PATCH] system: Add option to maintain a supervision tree J. Neuschäfer via buildroot
2024-07-14 21:11 ` Arnout Vandecappelle via buildroot
2024-07-18 20:53 ` J. Neuschäfer via buildroot [this message]
2024-07-14 22:12 ` Arnout Vandecappelle via buildroot
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=ZpmAvdJnGWB5T4DG@probook \
--to=buildroot@buildroot.org \
--cc=arnout@mind.be \
--cc=j.neuschaefer@gmx.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.