From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2816 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Guillermo Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: The "Unix Philosophy 2020" document Date: Sat, 28 Dec 2019 15:05:59 -0300 Message-ID: References: <20190901091157.bjtfhqq6d2rg75yo@caspervector> <20190927083816.tectynx7dzlfcvb7@caspervector> <20191012173743.drzlgnrw4hib6hh4@caspervector> <20191117062644.lt6wfmqwijqqhc5w@caspervector> <20191226175258.o2nsregew6tlqlbu@caspervector> <20191227112309.3fow6vynss2ifw4t@CasperVector> <20191228022440.GA194581@cube> <20191228135725.5b1b0cce7039e7af13bae601@obarun.org> <20191228140453.GB198054@cube> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="67987"; mail-complaints-to="usenet@blaine.gmane.org" To: Supervision Original-X-From: supervision-return-2405-gcsg-supervision=m.gmane.org@list.skarnet.org Sat Dec 28 19:06:09 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 1ilGTY-000HWM-Ez for gcsg-supervision@m.gmane.org; Sat, 28 Dec 2019 19:06:08 +0100 Original-Received: (qmail 29304 invoked by uid 89); 28 Dec 2019 18:06:34 -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 29297 invoked from network); 28 Dec 2019 18:06:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=00h9ByZw7zoP/jg9QNXiktC+rqSs5HAmCooov450/pw=; b=OXAdDm9vQURjAuVOiqsJWtxQZbfdym36Qw7nYK3CZjujayx/jStuT3ChdHcAjwv/ys NcTmQ5s1jMC48KTDy/2VurMY9fgQz2mCIVIHFh7lnLZRlmqxErBwt9oA6TMvo/heUkW2 SPHCBQGB+hRG37RUGJSpmYyKRzH90YyKxcrRvu8XXNTpbPqL91UqPEgt8SR0QoUSFnfg 6qwDSM9hE8bQFw/w2WA6Qx2CEVVKtyV+6F9bS/eT45dFBWFjGGwML1W8GKXpdVnRYll4 0CGJ148ylGiK24sRMph9l10QCE1bk8KnGMUK6Dnlf+2h/aDNVbQpPxXA+9tyLR+/uLLd vn0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=00h9ByZw7zoP/jg9QNXiktC+rqSs5HAmCooov450/pw=; b=uD5flEGuG5P3GmXotQbgnxg70snzzjfgRZyvwUs9XWE80UeNS99SCc9NXPkkKv+faU 47qwKc3N2snPlDSBzD1CyU1TVzPn+i7Bu3Q15wGk2DIjZa9cPfIV34b/SQGQmX6XIoDR PPL4pVjX+0KaBLAkE5VOigABLyWkF/CMwGajjdAN7u+b/7fZD/F+Gy1dF8GhT3Zu8ooK PkwN7i4PvfNPdbVp5raCXgdXS2UIeI4e20wMfdDWbXP30RUbK6wfcdTD7nW9Tc+1Q7vQ 3ZHLq7Ct0Bi5QFrPp/mBbpm/7j45zPQ781Fb874xuSMZp1tr/c3LxiNK+52AxWqQcg92 Wu7g== X-Gm-Message-State: APjAAAVP3B6Kz4HNKQdqgKt5Tvq+IgrSaVUKA2vRsqv7I0HyD7wSP7ro iyJzN4YyzX9M6dfsi+Fso5iCMnc2aYe3vl3+DzsOLg== X-Google-Smtp-Source: APXvYqzIAKC+MhdpMqc76ikogu7zPASIGz1Ojm3cGPbOdtJ5pCWjmDdgA34IaZpQIfifSI4a0oSROY/N2yynT0S96rU= X-Received: by 2002:a92:c8c4:: with SMTP id c4mr50757602ilq.38.1577556366484; Sat, 28 Dec 2019 10:06:06 -0800 (PST) In-Reply-To: <20191228140453.GB198054@cube> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2816 Archived-At: El s=C3=A1b., 28 dic. 2019 a las 11:06, Alex Suykov escribi=C3=B3: > > Minor note on this. Resource limiting with cgroups does not require > any explicit support from s6, or any external tools for that matter. > Literally just `echo $$ > $cg/cgroup.procs` in the startup script > is enough, assuming the group has been created (mkdir) and the limits > have been set (bunch of echo's). Exactly. And that's what nosh's move-to-control-group(1) and set-control-group-knob(1) do. They are convenience tools invoked by nosh scripts generated by conversion of unit files (with 'system-control convert-systemd-units'). Nosh's service manager doesn't directly deal with cgroups, and neither does its PID 1 program. > The whole thing regarding cgroups in systemd is really about a very > different problem: supervising broken services that exit early and > leave orphaned children behind. I'm not sure if it is specifically for that. AFAIK, it is an implementation detail of 'KillMode=3Dcontrol-group' and 'KillMode=3Dmixed' unit file directives. Daemons that use those, like GDM, seemingly 'stay in the foreground', and can therefore be supervised, but spawn child processes (and/or threads?) that they expect someone else to kill when they exit. * https://www.freedesktop.org/software/systemd/man/systemd.kill.html#KillMo= de=3D * https://gitlab.gnome.org/GNOME/gdm/blob/3.34.1/data/gdm.service.in (A BusName directive and no Type directive means, I think, that the process can be supervised, and should be considered ready when it acquires a bus name) For those cases, I believe only the "read PIDs from cgroup.procs and kill corresponding processes until no more PIDs are read" part of the 'babysitter' functionality is needed, and IMO that fits better in the finish file, like in Oliver's example. As for the "Is there real pressure to have this?" question, I guess it depends on how many daemons that need o rely on this KillMode functionality actually exist? Do we know? G.