From: eric vidal <eric@obarun.org>
To: supervision@list.skarnet.org
Subject: Re: The "Unix Philosophy 2020" document
Date: Sat, 28 Dec 2019 13:57:25 +1100 [thread overview]
Message-ID: <20191228135725.5b1b0cce7039e7af13bae601@obarun.org> (raw)
In-Reply-To: <20191228022440.GA194581@cube>
> https://github.com/arsv/minibase/blob/master/src/misc/runcg.c
>
> It's really simple.
>
> I don't think a tool like this has any actual uses, other than in
> arguments with systemd fans, but I guess that alone could justify
> its existance.
Thanks for this link this is really interesting.
Well, for me, cgroups is clearly a lack to s6. Using it for every process like systemd do have no sense, but in some case it can be useful to protect e.g an "over-eat" allocation memory by a program (in particular over a server).
As cgroups is a linux specific feature, s6-supervise should not take care about it even if the code is modified at compile time. This will increase the code of s6-supervise only for an "optional" features. But laurent you do what you need to do.
I would prefer an extra layer of supervision and independent from s6 uniquely used when it necessary.
I think about it from a while for 66. Adding a section like [cgroups] containing all @key field needed to configure the future cgroups environment is not a big deal and allow user to quickly define what it need. In such case the "extra supervision layer" is added to the run scripts which execs the e.g runcg program.
But maybe i'm totally wrong with my thought...
--
eric vidal <eric@obarun.org>
next prev parent reply other threads:[~2019-12-28 2:57 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190831130730.ki6ma7i5curucowe@caspervector>
[not found] ` <em5af31b6f-4dd3-4a31-a6cf-beccb100238d@elzian>
[not found] ` <20190901091157.bjtfhqq6d2rg75yo@CasperVector>
2019-09-27 8:38 ` Casper Ti. Vector
2019-10-12 17:37 ` Casper Ti. Vector
2019-10-12 18:58 ` Steve Litt
2019-10-12 19:14 ` Casper Ti. Vector
2019-10-13 3:31 ` Casper Ti. Vector
2019-10-13 8:21 ` Oliver Schad
2019-10-13 13:57 ` Casper Ti. Vector
2019-12-08 17:04 ` Casper Ti. Vector
2019-10-14 6:35 ` Jens Rehsack
2019-10-22 15:33 ` Casper Ti. Vector
2019-10-22 16:54 ` Steve Litt
2019-10-22 17:07 ` Casper Ti. Vector
2019-11-17 6:26 ` Casper Ti. Vector
2019-11-17 7:28 ` Casper Ti. Vector
2019-11-24 20:13 ` Guillermo
[not found] ` <20191125025202.oqu4ennu3lexnxsa@caspervector>
2019-11-25 2:52 ` Casper Ti. Vector
2019-11-25 14:20 ` Casper Ti. Vector
2019-11-30 12:13 ` Jeff
2019-11-30 12:20 ` Jeff
2019-11-30 12:45 ` Jeff
2019-11-30 13:29 ` Laurent Bercot
2019-11-30 14:43 ` Casper Ti. Vector
2019-11-30 15:01 ` Jeff
2019-11-30 15:48 ` Casper Ti. Vector
2019-11-30 16:58 ` Jeff
2019-12-26 17:52 ` Casper Ti. Vector
2019-12-27 1:09 ` Oliver Schad
2019-12-27 11:11 ` Casper Ti. Vector
2019-12-27 2:57 ` Steve Litt
2019-12-27 13:54 ` Casper Ti. Vector
2019-12-27 15:37 ` Casper Ti. Vector
2020-01-04 9:10 ` Casper Ti. Vector
2020-01-04 18:25 ` fungal-net
2020-01-05 0:36 ` Casper Ti. Vector
2020-01-05 6:31 ` Casper Ti. Vector
2020-01-05 6:54 ` Casper Ti. Vector
2019-12-27 23:05 ` Steve Litt
[not found] ` <20191227135411.jbtxorloetcvv5bx@caspervector>
[not found] ` <20191227153719.2tt4bbidp3v7t23u@caspervector>
[not found] ` <20200104091013.wesvxvcqxquc5n2h@caspervector>
2020-01-04 12:32 ` Laurent Bercot
2019-12-27 21:29 ` Steve Litt
2019-12-27 23:34 ` Alex Suykov
2019-12-28 10:35 ` Casper Ti. Vector
2019-10-28 15:34 ` Avery Payne
2019-10-28 15:51 ` Casper Ti. Vector
[not found] ` <20190901091157.bjtfhqq6d2rg75yo@caspervector>
[not found] ` <20190927083816.tectynx7dzlfcvb7@caspervector>
[not found] ` <20191012173743.drzlgnrw4hib6hh4@caspervector>
[not found] ` <20191117062644.lt6wfmqwijqqhc5w@caspervector>
[not found] ` <20191226175258.o2nsregew6tlqlbu@caspervector>
2019-12-26 19:17 ` Laurent Bercot
2019-12-27 11:23 ` Casper Ti. Vector
2019-12-28 2:24 ` Alex Suykov
2019-12-28 2:57 ` eric vidal [this message]
2019-12-28 14:04 ` Alex Suykov
2019-12-28 18:05 ` Guillermo
2019-12-28 23:19 ` Oliver Schad
2019-12-28 18:12 ` Oliver Schad
2019-12-28 21:32 ` eric vidal
2019-12-28 6:46 ` Steve Litt
2019-12-28 13:37 ` Alex Suykov
2019-12-28 13:54 ` Casper Ti. Vector
2019-12-28 17:41 ` Oliver Schad
2019-12-28 18:29 ` Serge E. Hallyn
2019-12-28 23:16 ` Oliver Schad
2019-12-28 21:31 ` eric vidal
2019-12-29 16:07 ` Alex Suykov
2019-12-29 20:32 ` Oliver Schad
2019-12-28 10:26 ` Casper Ti. Vector
[not found] ` <20191227112309.3fow6vynss2ifw4t@caspervector>
2019-12-27 12:32 ` Laurent Bercot
2019-12-27 13:48 ` Casper Ti. Vector
2019-12-27 23:54 ` Oliver Schad
2019-12-27 23:56 ` Oliver Schad
2019-12-28 15:19 ` Guillermo
2019-12-28 18:16 ` Oliver Schad
2019-12-28 20:44 ` Laurent Bercot
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=20191228135725.5b1b0cce7039e7af13bae601@obarun.org \
--to=eric@obarun.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).