From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2556 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Steve Litt Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: interesting claims Date: Wed, 1 May 2019 03:26:14 -0400 Message-ID: <20190501032614.67c656b6@mydesk.domain.cxm> References: <11997211556565598@myt6-27270b78ac4f.qloud-c.yandex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="90300"; mail-complaints-to="usenet@blaine.gmane.org" To: supervision@list.skarnet.org Original-X-From: supervision-return-2146-gcsg-supervision=m.gmane.org@list.skarnet.org Wed May 01 09:26:23 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 1hLjdH-000NN2-DX for gcsg-supervision@m.gmane.org; Wed, 01 May 2019 09:26:23 +0200 Original-Received: (qmail 3093 invoked by uid 89); 1 May 2019 07:26:45 -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 3086 invoked from network); 1 May 2019 07:26:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; h=X-Originating-IP:Date:From:To:Subject:Message-ID:In-Reply-To:References:X-Mailer:MIME-Version:Content-Type:Content-Transfer-Encoding; s=default; d=troubleshooters.com; b=ZC2JqjPc4FvrUzSAyVOyxqHK9gAWqTKpkWOPc+GLAmiQatcTr6cA1j7zwrax/HszKeYtnU9dQ0If1Y7RD3qmcf0Cp1wqGQ76LDAk9VzK81oMdQ9sjjzhilsuDHcRZWJv8XS4UhCnpAmugh9Ii7SSQYcliqjg3LA1L96MdzcHWYM=; DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=troubleshooters.com; s=default; t=1556695574; bh=1FEx/IZjQ+F7CJOPF+DEVZjZwUs=; l=2638; h=X-Originating-IP:Date:From:To:Subject:Message-ID:In-Reply-To: References:X-Mailer:MIME-Version:Content-Type: Content-Transfer-Encoding; b=I0po/NeBjqdguqkRi7lAV1kNd5Ij2QBpHjUL5OxtXS5tw7wsFWfmZRbr2V+q/w2Xk Y9ugt7sw49SKgrmUviMlh43cK/X2X52DuTifF5mohdijklr6q67XFKKet4ufIWKzOB AT/+BK/ddieQOEC67ebzO0P22jLNzC73WrxmbNh4= X-Originating-IP: [72.188.224.222] In-Reply-To: <11997211556565598@myt6-27270b78ac4f.qloud-c.yandex.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2556 Archived-At: On Mon, 29 Apr 2019 21:19:58 +0200 Jeff wrote: > i came across some interesting claims recently. on > http://skarnet.org/software/s6/ > it reads > > "suckless init is incorrect, because it has no supervision > capabilities, and thus, killing all processes but init can brick the > machine." Oh, that. First of all, Suckless Init is a PID1 that forks an rc script and then hangs around reaping zombies. You could use that rc file to run supervision systems such as daemontools-encore and the supervision part of runit and s6. So Suckless Init is the PID1 part of an init system. It's 83 lines of C. There are three philosophies: 1) The supervision should be done by PID1: Supported by Laurent Bercot 2) The supervision should be done outside of PID1: Perhaps supported by Rich Felker in his http://ewontfix.com/about/ > > a rather bold claim IMO ! > where was the "correct" init behaviour specified ? > where can i learn how a "correct" init has to operate ? > or is it true since s6-svscan already provides such respawn > capabilities ? ;-) > > there is actually NO need for a "correct" working init implementation > to provide respawn capabilities at all IMO. > this can easily done in/by a subprocess and has 2 advantages: > > - it simplyfies the init implementation > > - process #1 is the default subprocess reaper on any unix > implementation and hence a lot of terminated zombie subprocesses > get assigned to it, subprocesses that were not started by it. > if it has respawn capabilities it has to find out if any of this > recently assigned but elsewhere terminated subprocesses is one of its > own childs to be respawned. if it has lots of services to respawn > this means lots of unnecessary work that could be also done > in/by a suprocess aswell. > > when do you kill a non supvervised process running with UID 0 > "accidently" ? when calling kill ( -1, SIGTERM ) ? > the kernel protects special/important processes in this case from > being killed "accidently", that's true. > but where do we usually see that ? in the shutdown stage, i guess. > and that's exactly where one wants to kill all process with PID > 1 > (sometimes excluding the calling process since it has to complete > more tasks). or when going into single user mode. > > so this looks like a rather artificial and constructed argument for > the necessity of respawn functionality in an init implementation IMO. > -- SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust