From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2551 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jeff Newsgroups: gmane.comp.sysutils.supervision.general Subject: further claims Date: Mon, 29 Apr 2019 23:33:47 +0200 Message-ID: <15044531556573627@iva6-ff1651a9aa83.qloud-c.yandex.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="8593"; mail-complaints-to="usenet@blaine.gmane.org" To: supervision Original-X-From: supervision-return-2141-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Apr 29 23:33:52 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 1hLDuK-00027g-6p for gcsg-supervision@m.gmane.org; Mon, 29 Apr 2019 23:33:52 +0200 Original-Received: (qmail 10136 invoked by uid 89); 29 Apr 2019 21:34:17 -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 10129 invoked from network); 29 Apr 2019 21:34:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1556573627; bh=eTV5xmZ4ewfz3+iMe3flE7QDDO+TReybTKNuw+5Cp5w=; h=Message-Id:Date:Subject:To:From; b=M/mT3EDlq0bQRA/86xT5T2R52wfPUhKggCA/BSbmaXJ6/Ybp66mApv/yaym+OWXt0 o2C3KV2Ue6ib+AHVP7GhDavIM5g9oQ8WgVMTFXNPZam0F8WvvNcM3izPneedH0LRa7 74gIxE5vvjqMJQXFyhWDRRLgNOKiA0GD9T+ofHnU= Authentication-Results: mxback14o.mail.yandex.net; dkim=pass header.i=@yandex.com X-Mailer: Yamail [ http://yandex.ru ] 5.0 Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2551 Archived-At: At http://skarnet.org/software/s6/why.html one can find further interesting claims: > The runit process, not the runsvdir process, > runs as process 1. This lengthens the supervision chain. haven't you claimed process #1 should supervise long running child processes ? runit fulfils exactly this requirement by supervising the supervisor. this simplifies both (runit-)init (it has only to compare the PIDs of terminated child processes with exactly 1 PID) and the supervisor runsvdir (the latter can do its usual business without the requirement to do process #1 specific work such as reacting to signals in a special way, running the 3 different init stages etc. one could also rightfully point out here that these are proces #1 specific tasks and not a supervisor's duties per se.). this lengthens the supervision chain but also has the additional advantage of a supervised supervisor. ;-) maybe runsvdir was not made to run as process #1 and this was just a hack its author came up with to replace (SysV) init totally. who knows ? but it works well (except that runit-init looks at /etc/runit/reboot etc after receiving SIGCONT which is no good idea at all since it requires unnecessary read-write access to the fs this files reside on. how about just reacting to signals, say use STGTERM to poweroff, SIGHUP to reboot, SIGUSR1 to halt, SIGUSR2 to reboot or poweroff and make signal handling scripts like /etc/runit/ctrl-alt-del etc just send one of those signals to process #1 when SIG(INT,WINCH) were received ? does not require any read-write fs access and looks much simpler to me.) "Artistic considerations": > runit has only one supervisor, runsv, for both a daemon and its logger. > The pipe is maintained by runsv. If the runsv process dies, the pipe > disappears and logs are lost. So, runit does not offer as strong a > guarantee as daemontools. sure, if (s6-)svscan dies one is in deep shit aswell, so what is the point here ? runsv gets restarted by runsvdir but the pipe is gone (are pipes really closed when the opening (parent) process exits without closing them itself and subprocesses still use that very pipe ?) > daemontools' svscan maintains an open pipe between a daemon and its logger, > so even if the daemon, the logger, and both supervise processes die, > the pipe is still the same so no logs are lost, ever, unless svscan itself dies. but: > perp has only one process, perpd, acting both as a "daemon and logger > supervisor" (like runsv) and as a "service directory scanner" (like runsvdir). > It maintains the pipes between the daemons and their respective loggers. > If perpd dies, everything is lost. same for (s6-)svscan here (at least for the pipes). > however, perpd is well-written and has virtually no risk of dying. the same holds probably for (s6-)svscan, i guess. > Since perpd cannot be run as process 1, > this is a possible SPOF for a perp installation but from a design perspective it seems as reliable as s6-svscan ? or not since it uses a more integrated desing/approach ? this design simplifies communication since tasks are not implemented in other tools running as its (direct) subprocesses. so all kinds of fifos/pipes used for IPC are not necessary anymore except one socket per perpd process for client connections and there is no need for further communication with subprocesses (except via signals).