From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2819
Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail
From: "Serge E. Hallyn" <serge@hallyn.com>
Newsgroups: gmane.comp.sysutils.supervision.general
Subject: Re: The "Unix Philosophy 2020" document
Date: Sat, 28 Dec 2019 12:29:59 -0600
Message-ID: <20191228182959.GB22101@mail.hallyn.com>
References: <20190927083816.tectynx7dzlfcvb7@caspervector>
 <20191012173743.drzlgnrw4hib6hh4@caspervector>
 <20191117062644.lt6wfmqwijqqhc5w@caspervector>
 <20191226175258.o2nsregew6tlqlbu@caspervector>
 <em9435eac3-9f93-4195-8980-5d4d1216a872@elzian>
 <20191227112309.3fow6vynss2ifw4t@CasperVector>
 <20191228022440.GA194581@cube>
 <20191228014608.1dc7f43e@mydesk.domain.cxm>
 <20191228133735.GA198054@cube>
 <20191228184156.5a1a590f@flunder>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226";
	logging-data="163061"; mail-complaints-to="usenet@blaine.gmane.org"
User-Agent: Mutt/1.9.4 (2018-02-28)
Cc: supervision@list.skarnet.org
To: Oliver Schad <oliver.schad@automatic-server.com>
Original-X-From: supervision-return-2408-gcsg-supervision=m.gmane.org@list.skarnet.org Sat Dec 28 19:30:12 2019
Return-path: <supervision-return-2408-gcsg-supervision=m.gmane.org@list.skarnet.org>
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 <supervision-return-2408-gcsg-supervision=m.gmane.org@list.skarnet.org>)
	id 1ilGqq-000gIf-B3
	for gcsg-supervision@m.gmane.org; Sat, 28 Dec 2019 19:30:12 +0100
Original-Received: (qmail 30449 invoked by uid 89); 28 Dec 2019 18:30:37 -0000
Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm
Original-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>
Original-Received: (qmail 30442 invoked from network); 28 Dec 2019 18:30:37 -0000
Content-Disposition: inline
In-Reply-To: <20191228184156.5a1a590f@flunder>
Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2819
Archived-At: <http://permalink.gmane.org/gmane.comp.sysutils.supervision.general/2819>

On Sat, Dec 28, 2019 at 06:41:56PM +0100, Oliver Schad wrote:
> On Sat, 28 Dec 2019 15:37:35 +0200
> Alex Suykov <alex.suykov@gmail.com> wrote:
> 
> > The reason I think it's mostly useless is because the only use case
> > for cgroup supervision is supervising double-forking daemons, which
> > is not a very smart thing to do. A much better approach is to get rid
> > of double-forking and then just directly supervise the resulting long
> > running process.
> > I can't think of any other cases where it would be useful.
> 
> I definitly have to correct you: cgroups are *NOT* designed to catch
> wild forking processes. This is just a side-effect ot them.
> 
> The purpose is to control resource limits, like CPU, RAM, Disk I/O and
> so on. So for linux it would definitly make sense to have an interface
> to the full feature set.

Note that with a few simple scripts, users (and daemons) can do this all
themselves.  Even without privilege, once set up at boot.  Years ago I
would run firefox and kernel builds with restricted memory and cpu,
with a dynamic (unprivileged) daemon freezing them when the cpu got over
a certain temperature.  Yeah that laptop wasn't the most reliable...

-serge