From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2825 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alex Suykov Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: The "Unix Philosophy 2020" document Date: Sun, 29 Dec 2019 18:07:39 +0200 Message-ID: <20191229160739.GA223426@cube> References: <20190927083816.tectynx7dzlfcvb7@caspervector> <20191012173743.drzlgnrw4hib6hh4@caspervector> <20191117062644.lt6wfmqwijqqhc5w@caspervector> <20191226175258.o2nsregew6tlqlbu@caspervector> <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=utf-8 Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="73851"; mail-complaints-to="usenet@blaine.gmane.org" To: supervision@list.skarnet.org Original-X-From: supervision-return-2414-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Dec 29 17:09:15 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 1ilb7y-000J8X-Ug for gcsg-supervision@m.gmane.org; Sun, 29 Dec 2019 17:09:15 +0100 Original-Received: (qmail 15892 invoked by uid 89); 29 Dec 2019 16:09:38 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 15885 invoked from network); 29 Dec 2019 16:09:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=oiQGkHBcFJnHmGGarD0dqtPwSaxvvJB9CBO10tF8ItI=; b=IzOTaf4zrLoZruRWiniMhSdiRZwdNkrHWftkvlMcmja8EjYhKHdOHNwOiKgGyg4qsW 1pc71dHe69pkVg0P+93/+7V1mIjvjIX88I7kc48/n4221cnjPPgcmCqJOnzz97rHSt3C QiitzBFj3zP0YXQ8eDdcd0+0W9I5xIkD7t1JYVG1dC9gfypCZqskmFAEV+AL2S/os3Un uNmfplb3RYKx1GgchmXCS4fGrOzKWLyF8kPlX/8M2TfKpyE6PACBFdgNyiqSQjY7ftuo Uz2oWxcQzJyhwOmXjB307eLukknHFLKBNxQvB1p2FNzMrE3Q1ry+O5D+4f62MwQFafkM Zjyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=oiQGkHBcFJnHmGGarD0dqtPwSaxvvJB9CBO10tF8ItI=; b=uYlv1ViuK19sH7U8b3om9EmjnXFBsm0dhO7YjHbxEhZZU/GywB95fenLx4bjjhBalV yBSbgWKGeufImzvyhszbjP1+AwtJHXdDRLwkwYEUbRkpjG85PK9sxPoPuq5R6uURdjBn fCHGckflYs2CZDo+BlDpEPrrnxBahKKahIsdIHe5aHIBs/Nqz9yejRDh8aoV6JCQSkpz tqysy6P0uKt9sBFdpcrObYJ6FJJfG6XQ1JRFidYh4n+MoOS14AlqgqODsiWIVWK9bASz nbi1B1qr1D/PjKzMYw/1LcHTQQW+pmH8ihULs5g6hksndp/B1byFcgTpru3xlcpqp9bK PAHg== X-Gm-Message-State: APjAAAWS33o6hxBDxhtTtXtx0aA5fg8RQRbjCVPunRYdXCnAtGqPDya4 5Rx7L3oMzq+FRYTPvpgREqsfP1Wo X-Google-Smtp-Source: APXvYqyQptjmdg3s+Obtj3fvFuYRfsPeNIGXwrNTAZ3UKjW3YkgQ7ibaWFQOV+iRKDAdBt0c6evfMw== X-Received: by 2002:ac2:4909:: with SMTP id n9mr36113582lfi.21.1577635750732; Sun, 29 Dec 2019 08:09:10 -0800 (PST) Content-Disposition: inline In-Reply-To: <20191228184156.5a1a590f@flunder> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2825 Archived-At: Sat, Dec 28, 2019 at 06:41:56PM +0100, Oliver Schad 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. Er, that whole quoted part, including the last sentence, is about using cgroups to supervise processes. Not about the use of cgroups in general. I can't think of any other use cases where cgroup supervision would be useful, other than for double-forking daemons. Also, wrt process supervision, calling it a side effect is bit misleading. The interfaces are not really made for that kind of use at all. Strictly speaking, anything doing kill `cat .../cgroup.procs` is racy and unreliable. Including that runcg tool that I wrote. In practice, the race is pretty much irrelevant, but it's still there, inherent to the interfaces.